From: David Abrahams (dave_at_[hidden])
Date: 2004-01-05 11:47:55
Douglas Gregor <gregod_at_[hidden]> writes:
> On Saturday 03 January 2004 03:35 pm, David Abrahams wrote:
>> I am inclined towards a new policy for Boost which requires compiler
>> identification only via BOOST_-prefixed macros.
> For workarounds, I agree. For extensions (such as the aforementioned #pragma
> once), we should allow use of non-BOOST_-prefixed macros, because vendors
> claiming compatibility with another compiler generally support the
> extensions... just not the weirdo bugs that Boost tends to encounter.
What didn't you like about Hartmut's argument?
It's a pain to re-iterate all the conditions and compilers, which
support the #pragma once for every
#if (defined(_MSC_VER) && _MSC_VER >= 1020) || defined(__WAVE__) || etc.
So I mandate for using a BOOST_... constant for this. The
Boost.Config headers are included first anyways, and not using a
#pragma once inside those shouldn't hurt so much.
Counting on the vendor-supplied macros to properly slice up the space
of extensions is just like counting on them to properly distinguish
compilers: it's gonna fail at some point, and in the meantime we'll
need to write ugly stuff like the above.
>> If we do that, we can also ensure that BOOST_CONFIG #defines all of
>> them (mostly to zero) and we can eliminate the issues with warnings
>> from BOOST_WORKAROUND doing comparisons on macros which haven't been
> I didn't realize there were such issues, but this is a good idea.
Good. What do we do about intel 8.0 for the 1.31.0 release? Should
we change all occurrences of __GNUC__ in the library? Sounds like a
bad bet before the release...
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk