[config] Why is BOOST_HAS_LONG_LONG defined in suffix.hpp?
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? 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? Markus
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.
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
But shouldn't this go into some prefix file instead of a postfile file?
We've always used the suffix file for stuff like this that is supposed to be "generic". Of course if we run into enough problems that might have to change, but I don't think we're there yet.
See http://tinyurl.com/aywa7, it failes because of missing support for long long in the iostream library.
Yep, I can reproduce that via HP-Testdrive, worse the std lib *does* support numeric_limits<long long>, it's just the iostreams stuff that's missing. As far as limits_test is concerned there's a workaround for the same problem with MSVC specifically for that test, I've tested the following patch as a workaround for gcc, and it fixes the issue for now, but we should probably add a new config macro or something if there are any other tests affected though. What do you think? Should this go into 1.33? It's probably a little close for comfort, Doug? John. RCS file: /cvsroot/boost/boost/libs/config/test/limits_test.cpp,v retrieving revision 1.12 diff -r1.12 limits_test.cpp 56a57,74
#if (defined(_GLIBCPP_VERSION) || defined(_GLIBCXX_VERSION)) \ && defined(BOOST_HAS_LONG_LONG) \ && !defined(_GLIBCPP_USE_LONG_LONG) \ && !defined(_GLIBCXX_USE_LONG_LONG) // // Some libstdc++ versions have numeric_limits<long long> but no // iostream support for long long. TODO, find a better fix!! // std::ostream& operator<<(std::ostream& os, long long i ) { return os << static_cast<long double>(i); } std::ostream& operator<<(std::ostream& os, unsigned long long i ) { return os << static_cast<long double>(i); } #endif
On Tue, 19 Jul 2005 11:41:40 +0100, John Maddock wrote
Yep, I can reproduce that via HP-Testdrive, worse the std lib *does* support numeric_limits<long long>, it's just the iostreams stuff that's missing.
As far as limits_test is concerned there's a workaround for the same problem with MSVC specifically for that test, I've tested the following patch as a workaround for gcc, and it fixes the issue for now, but we should probably add a new config macro or something if there are any other tests affected though. What do you think?
As I recall there were issues with lack of i/o support in some 2.92 versions of gcc as well -- but in any case date-time will benefit from this change b/c it depends on i/o for int64 and uint64. Jeff
As I recall there were issues with lack of i/o support in some 2.92 versions of gcc as well -- but in any case date-time will benefit from this change b/c it depends on i/o for int64 and uint64.
Perhaps I wasn't being clear: the proposed change fixes one test file only, it doesn't make those operators globally available - although that might not be a bad idea if we can figure out how to do that in a reasonably portable manner - but a global change like that (or a new config macro) really would have to wait until after 1.33. John.
On Jul 19, 2005, at 5:41 AM, John Maddock wrote:
But shouldn't this go into some prefix file instead of a postfile file?
We've always used the suffix file for stuff like this that is supposed to be "generic". Of course if we run into enough problems that might have to change, but I don't think we're there yet.
See http://tinyurl.com/aywa7, it failes because of missing support for long long in the iostream library.
Yep, I can reproduce that via HP-Testdrive, worse the std lib *does* support numeric_limits<long long>, it's just the iostreams stuff that's missing.
As far as limits_test is concerned there's a workaround for the same problem with MSVC specifically for that test, I've tested the following patch as a workaround for gcc, and it fixes the issue for now, but we should probably add a new config macro or something if there are any other tests affected though. What do you think? Should this go into 1.33? It's probably a little close for comfort, Doug?
Yes, go ahead with the change to the test. The config macro will have to wait until 1.34, of course. Doug
John Maddock wrote:
But shouldn't this go into some prefix file instead of a postfile file?
We've always used the suffix file for stuff like this that is supposed to be "generic". Of course if we run into enough problems that might have to change, but I don't think we're there yet.
You may be right.
See http://tinyurl.com/aywa7, it failes because of missing support for long long in the iostream library.
Yep, I can reproduce that via HP-Testdrive, worse the std lib *does* support numeric_limits<long long>, it's just the iostreams stuff that's missing.
BTW, spe171 is the machine where the boost regression tests are running. It has CXX V6.5-042 installed and gcc-3.3.6 and gcc-3.4.4 are located in /usr/local.
As far as limits_test is concerned there's a workaround for the same problem with MSVC specifically for that test, I've tested the following patch as a workaround for gcc, and it fixes the issue for now, but we should probably add a new config macro or something if there are any other tests affected though. What do you think? Should this go into 1.33? It's probably a little close for comfort, Doug?
The patch looks ok, and yes, I think we need a new config macro for this (BOOST_HAS_LONG_LONG_IO perhaps), because there are other libraries failing because of this. (Wave, utility, maybe more.) Thanks, Markus
participants (4)
-
Douglas Gregor -
Jeff Garland -
John Maddock -
Markus Schöpflin