Re: [boost] Boost.Math: Ignored trac patches

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
>>  #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. 
>   

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.

-- 
Bjørn