On Sat, Nov 17, 2012 at 4:33 AM, Matt Calabrese <rivorus@gmail.com> wrote:
I'm basically with everyone who's been saying to just not bother using "#pragma once" since the idiomatic ifdef guards work fine and unless there are some real benchmarks, I don't think it's worthwhile trying to bend over backwards to take advantage of something that's non-standard. I'm just not convinced there are any actual gains here.
On Fri, Apr 10, 2009 at 11:33 AM, Remko Tronçon <remko@el-tramo.be> wrote:
Anyway, I understand that a library like Boost doesn't want to rely on this, but personally, but it sounds sane to me that other projects (that are less depended on and don't need to support a gazillion of compilers) use it.
Alright, I'll agree with this. While I'm not convinced it's a great idea for boost to use #pragma once, a library macro for users that uses it when available might make sense. Assuming _Pragma support, it's trivial to provide a macro BOOST_INCLUDE_ONCE that is defined as _Pragma( "once" ) in compilers that support it and nothing in compilers that don't (avoiding possible unrecognized pragma warnings). An alternative is a macro that produces a compile-time error if it's not supported.
I would rather prefer BOOST_HAS_PRAGMA_ONCE macro in Boost.Config. Not all compilers support _Pragma (MSVC for one, and it's the primary target for the optimization), so I would still use #pragma guarded with the config macro. I know, in order to get BOOST_HAS_PRAGMA_ONCE defined I will have to include boost/config.hpp, but I do it anyway (so as most of Boost libraries, I presume). Disclaimer: I did not run performance tests to confirm the compile speed gains. But that #pragma once thing is almost a habit of mine, so it's not a big deal for me to add it to my headers.