Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk