Re: [boost] [config] Why is BOOST_HAS_LONG_LONG defined in suffix.hpp?

From: John Maddock (john_at_[hidden])
Date: 2005-07-18 07:33:52

> The first few lines of suffix.hpp currently look like this:
>
> #include <limits.h>
> # if !defined(BOOST_HAS_LONG_LONG)
>      \
>    && !defined(BOOST_MSVC) && !defined(__BORLANDC__)     \
>    && (defined(ULLONG_MAX) || defined(ULONG_LONG_MAX) ||
> defined(ULONGLONG_MAX))
> #  define BOOST_HAS_LONG_LONG
> #endif
>
> What is the reason for this code being there? Isn't it enough to test for
> this in the platform/compiler/stdlib config?

The code is intended to determine only whether the compiler has a long long 
data type, *not* whether there is any library support for it (although there 
must be some for the limits macros to be defined).

> I'm asking this question because currently stdlib/libstdcpp3.hpp
> explicitely turns off BOOST_HAS_LONG_LONG when the library indicates that
> there is no support for long long, and this is foiled by the code in
> suffix.hpp, which turns on BOOST_HAS_LONG_LONG again. (And this causes
> errors with gcc-3.3.x on Tru64.)
>
> Maybe we need two config macros for this? One for
> BOOST_COMPILER_HAS_LONG_LONG, and one for BOOST_STDLIB_HAS_LONG_LONG?
>
> Comments or thoughts, anyone?

It looks like Jens Maurer's fix in libstdcpp.hpp doesn't do what he thought 
it did: the idea is that BOOST_HAS_LONG_LONG refers to the compiler only. 
After all there are some parts of Boost (like type_traits) that can make use 
of it, and do the right thing without any library support.

We also have  BOOST_NO_LONG_LONG_NUMERIC_LIMITS, but that may not refer to 
the part of the library you want to use.  What failures on Tru64 are you 
seeing because of this?

John.