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.