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

From: David Abrahams (dave_at_[hidden])
Date: 2004-01-05 15:42:17

Douglas Gregor <gregod_at_[hidden]> writes:

> 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

Well, by convention,

   #elif BOOST_WORKAROUND(BOOST_GCC, != 0) || BOOST_WORKAROUND(BOOST_BORLAND, < 0x600)

or probably much better:

   #elif BOOST_WORKAROUND_GCC(!= 0) || BOOST_WORKAROUND_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)

Ick!

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

I think we agree then (unless of course you hate my functional
macros) ;-)

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

I think we can probably nail those individually on the branch for this
release, no?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com