Boost logo

Boost :

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2007-12-15 07:58:26

John Maddock wrote:
> Jens Seidel wrote:
>> I just want to mention that
>> #include <boost/math/complex/details.hpp>
>> is easier to read than
>> # 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.

I hate guards around #include, if that counts ;-)

> If more compilers would follow GCC's lead and automatically recognise
> include guards, the the discussion would be moot anyway...

Huge improvement....,
but I also hate traditional include guards inside the header files. The
ideal solution before we get modules in the language would be to change
the default behaviour in preprocessors so the typical use case "#include
once" became the default and that we had to explicitly declare use case
of unrestricted inclusion, "#include unrestricted".

Ok, this may not be realistic given that it would break some code which
depend on headerfiles being read multiple times. But without the change
in default, the removal of the need for the error prone, none-intuitive,
and extremly ugly traditional include guards would a move forward for
the language. There are two areas that are problematic with such a
direction for language support of file include restrictions.

The first area is to find a smooth migration path. I think this is the
worst problem. A good example of this is the situation with regard to
portable use of the MS "#pragma once" extention. If it had imediatly
been adapted by all compiler vendors, then the pragmatic C++ comunity
migth have adapted it as the standard, alothough "#once" would have done
the trick after standarization. This would have been a huge improvement
over the traditional include guards. The advantage with this approach
is that current default is not broken, but then we would never get the
default that make sence. The problem with #pragma once is however that
there is no way of smooth portable migration. Avoiding horribly ugly
code is impossible, just look every place in boost it is used. As long
as there is no implemented standard for this, it is basically not a way
forward in my mind.

The other problem area is the exact standard text. What are the required
behaviour of (pre)compilers? What guaranties are compilers required to
implement by the standard? I think this is quite possible to work out
if preformance of compilation is something we would expect from a good
implementation, but not require by the standard. I.e. if the compiler
need to rescan the file to be sure the content is identical, it should
be allowed to do so. Use of hash checksums, filesystem/OS features, SCM
features, etc. to achive performance under these requirements should
entirely be a an implementation detail.

Under the current situation, I think the #pragma once should be removed
from portable code. It is just too ugly to justify as long as we also
need the traditional include guards. Sorry all msvc fans, that is my
vote. Ask MS to fix their compiler to be effective under the current
standard or help fix the standard if they need efficiency.


Boost list run by bdawes at, gregod at, cpdaniel at, john at