> >> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
