David Abrahams wrote:
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.
I agree. There are some compilers, like GCC, in which there is more rarely a distinct version, meaning major and minor version numbers. But there are many compilers which work with that sort of release scheme, such as Microsoft, Borland, Intel, CodeWarrior, Comeau etc. GCC is the oddity which puts out slightly changed releases quite often, because it is free and open source. Most other compilers have specific versions which do not change for a good amount of time.
( 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?
Yes, I have. BOOST_WORKAROUND is of course more flexible. What I wanted to offer was a set of macros, for compilers supporting distinct versions which stay the same for a fairly long time, so that the workaround code could be more readable. That's all really. I realize that with BOOST_WORKAROUND one can add a comment saying to what each workaround actually refers, but this is often not done. Furthermore I see quite a bit of code, whether rightly or wrongly, which does not use BOOST_WORKAROUND. My solution, if you are interested, also allowed a still released distinct version macro for a compiler to be easily changed if the version encompassed a range of preprocessor macro values, so that, as an example, if VC8 SP1 comes out and _MSC_VER changes for it to 1410, a single change in a single file updates the appropriate macros. Of course it is trivial to do that...
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.
We would not so much as lose the functionality as offer a more simplistic and readable way to express it. My suggestion is just about readability. When I see: #if BOOST_WORKAROUND(nnnn,comparison operator) I often can not tell to what it refers without some comment. But if I saw, as an example: #if BOOST_COMPILER_VC71 it becomes easier to understand. Anyway if Boost developers are happy with understanding workarounds by only using preprocessor symbols in comparisons, whether using BOOST_WORKAROUND or otherwise, I do not want to change things. And you are right in that adding a set of new macros, although all would start with BOOST_COMPILER_, might be overkill. I like syntactic sugar if it produces greater readability and the cost is very small. I just found all the proprocessor macro version number references in BOOST_WORKAROUND and bare #if statements annoying. I thought the code would be much easier to read if the #if statement referred to distinct compiler versions. Even GCC does put out general versions which could be tagged in such a way as to make the reading of the code more understandable. I also think Boost should have somewhere a document or table which relates each distinct version of a compiler to a range of the appropriate preprocessor version numbers. If one has the compiler on one's machine, I believe the config.cpp test will tell that, but if one does not have the compiler it is impossible to tell.