John Maddock wrote:
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).
But shouldn't this go into some prefix file instead of a postfile file?
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?
See http://tinyurl.com/aywa7, it failes because of missing support for long long in the iostream library. Markus