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

From: Douglas Gregor (gregod_at_[hidden])
Date: 2004-01-05 14:51:11

On Monday 05 January 2004 11:47 am, David Abrahams wrote:
> 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 good argument for introducing configuration macros when compiler checks 
start to get ugly, as the #pragma once checks have. The problem we're having 
with Intel 8.0 is that one compiler is masquerading as another. 

Perhaps I don't understand exactly what your policy entails. Here's one 
snippet from the type traits library that could be affected by Intel 8.0:

#elif defined(__GNUC__) || defined(__BORLANDC__) && (__BORLANDC__ < 0x600)

Are you proposing that the policy mandate, e.g.

        a) #elif BOOST_CC_GCC > 0 || BOOST_CC_BORLAND < 0x600

or must we introduce a new macro for the check this is meant to do:

        b) #elif defined(BOOST_WARNS_ON_UDT_PASSED_THROUGH_ELLIPSIS)

If you're proposing (a), I agree fully [and retract my weak preference for 
allowing extension checks to skip the BOOST_CC_xxx macros). If you're 
proposing (b), I disagree on the basis that we'd end up with tons (hundreds?) 
of macros for little checks like this. (b) is just too much maintenance for 
very little benefit, IMHO.

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

Too dangerous, IMHO. Looking through the regression tests, there are only two 
tests for which Intel 8.0 passes on Wintel but fails on Linux (and also fail 
on GCC, so they're probably related to __GNUC__ being defined): 
tricky_is_enum_test and interoperable_fail. I don't think it hurts us much 
for 1.31.0, so we should just start making these changes on the main trunk.

        Doug