From: Andrew Crabtree 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: ; from "Hans-Bernhard Broeker" at Feb 11, 98 4:06 pm Reply-To: andrewc AT rosemail DOT rose DOT hp DOT com Precedence: bulk > 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.