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

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2005-07-18 08:01:07

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