From:	Andrew Crabtree <andrewc AT typhoon DOT rose DOT hp DOT com>
Message-Id:	<199802111841.AA202772468@typhoon.rose.hp.com>
Subject:	Re: char != unsigned char... sometimes, sigh
To:	broeker AT physik DOT rwth-aachen DOT de (Hans-Bernhard Broeker)
Date:	Wed, 11 Feb 1998 10:41:07 PST
Cc:	Vik DOT Heyndrickx AT rug DOT ac DOT be, dj AT delorie DOT com, djgpp-workers AT delorie DOT com
In-Reply-To:	<Pine.LNX.3.93.980211151419.1113D-100000@acp3bf>; from "Hans-Bernhard Broeker" at Feb 11, 98 4:06 pm
Reply-To:	andrewc AT rosemail DOT rose DOT hp DOT com

> That may well be so, but does that mean we have to follow what is actually
> just a tradition, based in the day when 'inline' functions weren't
> available yet in most compilers?
Remember its not in the ANSI standard either.  

> After all, as the gcc docs state it 'an
> inline function is as fast as a macro', but it does have the benefit of
> type-safeness, and automatic demotion to a function call if the compiler
> thinks that's a better idea in a given situation.
The docs are *wrong*.  It should read that inlines *can* be as fast as a macro
under some circumstances.  There was recently a discussion on gcc2 about 
changing the docs to reflect this.  One particular case noted (which wouldn't 
affect what we are talking about here), is calling a macro vs calling an inline
with a constant longer than 32 bits.  For instance, macro("long string") vs
inline("long_string"). 

> > Because of the gnu c compiler optimization strategies. According to the
> > manual, you can't just assign enough to temporary variables. If you have
> > a look at the produced asm code, you will that this is correct. 
> OK. For now, I'll have to take your word on this. But I may investigate
> myself some time... 
Its more noticable with pointer operations, but true overall non-the-less.  
I don't suggest writing code this way though.

- Raw text -