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