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