From: John Maddock (john_at_[hidden])
Date: 2007-12-15 04:49:05
Jens Seidel wrote:
>> Why? It makes no difference, except to improve performance for
>> compilers that don't implement the include-guard detection trick
>> that gcc uses.
>
> Heh? What trick?
GCC has an optimisation: it spots when a file has already been included and
auto-magically prevents it from being included twice, if the effect would be
to include an empty file. It's similar to Microsoft's #pragma once but
automatic.
> To ensure that an include file is not included twice one normally
> defines a unique preprocessor macro at the beginning of the header
> file
> and skips processing if it was previously defined.
>
> Doesn't every Boost header does this? Do you consider using #define a
> trick?
That's not what I'm talking about, and those files do use the std include
guard mechanism, it's just that's there's a second catch to prevent multiple
inclusion, so the file doesn't get opened twice. But in all honesty it's a
triviality ;-)
> I just want to mention that
> #include <boost/math/complex/details.hpp>
> is easier to read than
> #ifndef BOOST_MATH_COMPLEX_DETAILS_INCLUDED
> # include <boost/math/complex/details.hpp>
> #endif
>
> It is also more secure because you increase the chance to make a typo
> in
> the macro which could be hard to track down.
> You're right that it could be a little bit faster but I have never
> seen
> it somewhere (including Boost).
As noted by Edward, various vendors use this in their own headers.
Is it a good idea? I don't know, I think the jury is still out on that one.
If more compilers would follow GCC's lead and automatically recognise
include guards, the the discussion would be moot anyway...
John.