Re: [boost] Re: Request: BOOST_ENABLE_LONG_LONG

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
> ...
> #endif
>
>
> (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.

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm