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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk