[boost] Re: Intel C++ for Linux defines __GNUC__!!

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.
        #pragma once
        #endif

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