Jens-Heiner Rechtien wrote:
Stephan Bergmann wrote:
Jens-Heiner Rechtien wrote:
Jan Holesovsky wrote:
Hi Thorsten,
On Monday 18 December 2006 11:46, Thorsten Behrens 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? Ie. is
this a modest gain in machine time compared to a perhaps much
costlier
loss of human time? Can you provide some numbers to support this
optimization or should we perhaps be conservative and not use it? ;-)
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 (as long as there
are build time degradations on at least one prominent platform, at
least when building on a network volume). Rather sooner than later,
all used compilers will perform this optimization by themselves, and
I'd say let's add the rule then. I'm relatively indifferent about
this, though - 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?
AFAIK GCC and SunStudio know about the "include guard optimization"
and do not need this. These platforms also do have no problem with
caching a few files even if they are served from a remote volume, so
it hardly wouldn't matter anyway. The one remaining compiler is
Microsoft Visual Studio. There are varying reports if this compiler
has a build-in "include guard optimization" or not. The acid test
would be a build on Windows vs. a remote Samba or NFS volume (some
people have such a setup). If the compile speed drops no more than -
say - 5 to 10% we IMHO could do away with these ugly things.
Heiner
As I said before on this thread, makedepend (or whatever the tool is
called exactly) did not implement the include guard optimization when
I last checked a couple of years ago. (And makedepend is called
before the compiler, on all platforms.)
But the call for makedepend has been changed :-) We create now
dependencies for all *.cxx in a directory in one step. Resulted in a
huge speedup, especially on Windows :-)
In this mode every header is only parsed once so it shouldn't make much
of a difference. Would still need to be tested, of course.
If I remember correctly, I checked with a degenerate case with 100
headers where each header includes all the others, and one cxx that
includes all headers. I am not sure this scenario improves when calling
makedepend once for all cxx combined (of which there is only one in this
case, anyway) instead of once for each cxx individually.
-Stephan
Heiner
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
