[config] Why does BOOST_NO_INTEGRAL_INT64_T depend on BOOST_HAS_LONG_LONG?
 
            Currently config/suffix.hpp contains the following code which seems pretty wrong to me: ---%<--- #if !defined(BOOST_HAS_LONG_LONG) && !defined(BOOST_NO_INTEGRAL_INT64_T) # define BOOST_NO_INTEGRAL_INT64_T #endif --->%--- AFAICT, the existence of a 64 bit integral type has nothing to do with support for long long types. On Tru64 for example, uint64_t is defined as unsigned long and there is no unsigned long long when the compiler operates in strict ansi mode. Shouldn't these lines just be removed? Markus
 
            Currently config/suffix.hpp contains the following code which seems pretty wrong to me:
---%<--- #if !defined(BOOST_HAS_LONG_LONG) && !defined(BOOST_NO_INTEGRAL_INT64_T) # define BOOST_NO_INTEGRAL_INT64_T #endif --->%---
AFAICT, the existence of a 64 bit integral type has nothing to do with support for long long types. On Tru64 for example, uint64_t is defined as unsigned long and there is no unsigned long long when the compiler operates in strict ansi mode.
Shouldn't these lines just be removed?
Oh, !*>&*$! Yes, but if they are removed other stuff will break, I can pretty much guarantee that. So how long away is the release? My gut feeling at present is to fix this after 1.33 goes out, but I could go either way I guess. John.
 
            John Maddock wrote:
Currently config/suffix.hpp contains the following code which seems pretty wrong to me:
---%<--- #if !defined(BOOST_HAS_LONG_LONG) && !defined(BOOST_NO_INTEGRAL_INT64_T) # define BOOST_NO_INTEGRAL_INT64_T #endif --->%---
AFAICT, the existence of a 64 bit integral type has nothing to do with support for long long types. On Tru64 for example, uint64_t is defined as unsigned long and there is no unsigned long long when the compiler operates in strict ansi mode.
Shouldn't these lines just be removed?
Oh, !*>&*$!
Yes, but if they are removed other stuff will break, I can pretty much guarantee that.
So how long away is the release?
My gut feeling at present is to fix this after 1.33 goes out, but I could go either way I guess.
Currently, Tru64/CXX strict mode compilation is affected by this. So why not just try it and if there are too much failures, revert it back? Markus
 
            Currently, Tru64/CXX strict mode compilation is affected by this. So why not just try it and if there are too much failures, revert it back?
If you're willing to deal with the regressions, and the review manager agrees, then it's OK with me: but check with Doug Gregor first. John.
 
            John Maddock wrote:
Currently, Tru64/CXX strict mode compilation is affected by this. So why not just try it and if there are too much failures, revert it back?
If you're willing to deal with the regressions, and the review manager agrees, then it's OK with me: but check with Doug Gregor first.
Doug, are you listening?
 
            John Maddock wrote:
Currently, Tru64/CXX strict mode compilation is affected by this. So why not just try it and if there are too much failures, revert it back?
If you're willing to deal with the regressions, and the review manager agrees, then it's OK with me: but check with Doug Gregor first.
I had another idea. I'll change the code in question to: ---%<--- #if !defined(BOOST_HAS_LONG_LONG) && !defined(BOOST_NO_INTEGRAL_INT64_T) \ && !defined(__DECCXX_VER) # define BOOST_NO_INTEGRAL_INT64_T #endif --->%--- This will leave other compilers/platforms alone and works around the issue on Tru64/CXX. And of course I'll add a comment that the whole thing should be removed after the release. Is this ok with you? Markus
 
            This will leave other compilers/platforms alone and works around the issue on Tru64/CXX. And of course I'll add a comment that the whole thing should be removed after the release.
Is this ok with you?
Sounds more sensible at this stage of the release, don't let me forget about this post release though! John.
 
            John Maddock wrote:
This will leave other compilers/platforms alone and works around the issue on Tru64/CXX. And of course I'll add a comment that the whole thing should be removed after the release.
Sounds more sensible at this stage of the release, don't let me forget about this post release though!
Ok, commited. And I'll try to remind you to remove it after the release. :-) Markus
 
            John Maddock wrote:
This will leave other compilers/platforms alone and works around the issue on Tru64/CXX. And of course I'll add a comment that the whole thing should be removed after the release.
Is this ok with you?
Sounds more sensible at this stage of the release, don't let me forget about this post release though!
ping :-)
participants (3)
- 
                 John Maddock John Maddock
- 
                 Markus Schöpflin Markus Schöpflin
- 
                 Markus Schöpflin Markus Schöpflin