From: John Maddock (jm_at_[hidden])
Date: 2003-02-13 06:52:59
> >> Could we subordinate BOOST_HAS_LONG_LONG to
> >> defined(BOOST_ENABLE_LONG_LONG)?
> >Even if we're willing to break user code and tell them they have to
> >define that macro explicitly, we'd have to be very careful; we have
> >tests that exercise long long and we don't want to break those or
> >disable that part of the testing.
> Yes. Those tests would simply have to #define BOOST_ENABLE_LONG_LONG.
> All the rest would remain the same.
> The idea was for defined(BOOST_ENABLE_LONG_LONG) to be a necessary
> (but not sufficient) condition to *define* BOOST_HAS_LONG_LONG. At the
> point of usage one would still deal with BOOST_HAS_LONG_LONG only, and
> the typical code snippet involving long long would still appear as:
> #ifdef BOOST_HAS_LONG_LONG
> (Maybe the idea is clearer if one mentally renames BOOST_HAS_LONG_LONG
> to BOOST_USE_LONG_LONG)
I hear what you say, but I keep coming back to: this is largely an Intel
compiler specific problem, and most users really do expect their libraries
to support long long whenever the compiler does. Personally I don't want to
have to answer a flood of questions along the lines of "why doesn't
some_type_trait<long long> work correctly?", remember that we already have
had a minor flood of requests for better long long support in various
libraries (mainly integer).
So... under what conditions should we not define BOOST_HAS_LONG_LONG for the
Intel compiler - is this a version thing - I thought all recent EDG front
ends defined __NO_LONG_LONG when it's not available? (How do the platform
headers detect whether long long is supported or not?) I guess we could
also add BOOST_DISABLE_LONG_LONG as well if it's really required.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk