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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
