Edward Diener <eddielee@tropicsoft.com> writes:
David Abrahams wrote:
Edward Diener <eddielee@tropicsoft.com> writes:
David Abrahams wrote:
Edward Diener <eddielee@tropicsoft.com> writes:
It would be much easier, and less confusing, when looking at compiler workarounds in Boost code if their were defines for various compilers/versions in a configuratiion header file such as:
#define BOOST_COMPILER_SOME_COMPILER_LOWER (PREPROCESSOR_TAG >= nnnn) #define BOOST_COMPILER_SOME_COMPILER_UPPER (PREPROCESSOR_TAG <= nnnn) #define BOOST_COMPILER_SOME_COMPILER (BOOST_COMPILER_SOME_COMPILER_LOWER && BOOST_COMPILER_SOME_COMPILER_UPPER)
Not sure why you'd want to do that. Then you only get a binary value for BOOST_COMPILER_SOME_COMPILER.
You would get a boolean of true or false.
That wouldn't be very useful in Boost. If you look through Boost code you'll find a lot of places where a <, <=,>, or >= comparison is needed against a compiler version.
The way I have set it up, for example, is to use
#define BOOST_COMPILER_VC6 (...) #define BOOST_COMPILER_VC6_OR_LOWER (...) #define BOOST_COMPILER_VC6_OR_HIGHER (...)
That would be nasty for a compiler such as GCC. Go take a look at the releases page.
( along with th same for VC7, VC71, and VC8 )
You could write:
#if BOOST_COMPILER_VC6 // code #endif
or
#if BOOST_COMPILER_VC6_OR_HIGHER (...) // code #endif
or even
#if BOOST_COMPILER_VC6 || BOOST_COMPILER_VC7 // code #endif
You can imagine the ease of any combinations you like.
Of course if one would rather see:
#if (BOOST_MSVC >= 1310) // code #endif
or
#if BOOST_WORKAROUND(BOOST_MSVC,>= 1310)+ // code #endif
because that is better, then why should I suggest otherwise ?
I don't know. It doesn't only have to do with what I'd rather see, but with the functionality provided by BOOST_WORKAROUND. Have you read the entire comment there?
I'd rather have a composite version number.
I would rather know whether some compiler is being referred to or not.
Then learn what the version numbers mean?
Specifying a compiler version via a macro makes the code much clearer. This does not keep anyone from using BOOST_MSVC if they like or even combining it with the compiler identiification macros shown above.
I'd rather have one consistent way to do these tests than have a giant suite of testing macros for every compiler and version.
Well, I think I spoke too soon. What you appear to be asking for would add little of value to Boost and would undermine the capabilities we get from BOOST_WORKAROUND.
I would never want to "undermine" Boost code in any way.
Maybe that wasn't the best choice of words. I just meant that we'd lose the functionality provided by BOOST_WORKAROUND if we started using the macros you suggest instead. -- Dave Abrahams Boost Consulting www.boost-consulting.com