Re: External header guards

Jens-Heiner Rechtien schrieb:
> Jan Holesovsky wrote:
>> On Monday 18 December 2006 11:46, Thorsten Behrens wrote:
> Kai Backman wrote:
>>>> Aah. Let me rephrase. Are -you- really sure the external include guard
>>>> optimization provides enough benefit on all the compilers we are using
>>>> to make it worthwhile to degrade readability by adding noise?

>>> ok, seems we've deadlocked here. ;-)

>>> Point is, the vast majority of the code uses that idiom as of today,
>>> and I'm reluctant to advice people of the contrary
>>> [...]
>>> - if people think it's ok to start removing external
>>> header guards right now (because it will take years to clean them up
>>> anyway), I'd be fine with that, too.
>>
>> I hate them that much that I am willing to do a script that would do
>> the removal ;-)
>>
>> What is the platform/compiler that probably needs this, please?  Any
>> volunteer to do a comparison of the "with" and "without" compilation
>> times?
>
> The one remaining compiler is Microsoft Visual
> Studio. There are varying reports if this compiler has a build-in
> "include guard optimization" or not.

According to Oliver Bolte, in version 8, the MSVC compiler uses the 
trick to connect a define (of an internal include guard) with the 
correlating header, which is one possble way to implement this, but v.7 
does not.


Anyway, I would go with Thorstens remark: We will need years to remove 
the existing external include guards anyway. IMHO there is no 
significant performance gain by adding more of them now.

So my
Suggestion
----------
is: From today on, we use internal include guards only.
Until this has a measurable effect on our build times, we will use a 
newer version of MSVC.

What do you think?

Nikolai