Re: [boost] Defining compilers suggestion

From: Edward Diener (eddielee_at_[hidden])
Date: 2005-07-11 07:17:36

David Abrahams wrote:
> Edward Diener <eddielee_at_[hidden]> writes:
> 
> 
>>David Abrahams wrote:
>>
>>>Edward Diener <eddielee_at_[hidden]> writes:
>>>
>>>
>>>
>>>>David Abrahams wrote:
>>>>
>>>>
>>>>>Edward Diener <eddielee_at_[hidden]> 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.