Re: [boost] Defining compilers suggestion

From: David Abrahams (dave_at_[hidden])
Date: 2005-07-13 14:17:22

Edward Diener <eddielee_at_[hidden]> writes:

> David Abrahams wrote:
>> Edward Diener <eddielee_at_[hidden]> writes:
>> 

> The idea, for any compiler, is that the preprocessor symbol name
> need not be remembered for BOOST_WORKAROUND's first parameter but
> that instead one would use a much easier name like BOOST_COMPILER_VC
> for Visual C++ or BOOST_COMPILER_BORLAND for C++ Builder etc. In
> fact an actual case supporting this idea was recently posted on this
> NG, where someone erroneously used BORLANDC instead of __BORLANDC__
> in such a manner. My suggesting is to eliminate this sort of error
> by providing an easier to remember macro name instead.

I already said I supported such an idea long ago in this thread (maybe
my 1st or 2nd post?).  For Visual C++ the current macro is

   BOOST_MSVC

I don't see a strong need to add "COMPILER_".  However, people will
still be able to misspell these macros unfortunately.

>> Okay, I understand what you're driving at.  I'm not sure if going down
>> this road is worth the trouble, but if it is, I'd rather see a
>> standard system for referring to versions numerically.  So, for
>> example:
>> 
>>         Version   Value
>>         -------   -----
>>         6.0       060000
>>         6.0sp5    060005
>>         7.0       070000
>>         7.1       070100
>>         5.3.4     050304
>>         3.4.3     030403
>>         2.95.3    029503
>> 
>> I don't particularly think 
>> 
>>   BOOST_COMPILER_VC == BOOST_COMPILER_VC71_VERSION
>> 
>> is more expressive than
>> 
>>   BOOST_MSVC_VERSION == 070100
>
> It is more expressive than some long number because the former encompasses the 
> idea of a version of Microsoft VC++. I am trying to create a set of macros which 
> equate to version numbers of compiler releases but which also allow boolean 
> comparisons for that release. That is why I have BOOST_COMPILER_XXX_VERSION and 
> BOOST_COMPILER_XXX_VERSION_HIGH for the former and BOOST_COMPILER_XXX, 
> BOOST_COMPILER_XXX_OR_HIGHER, and BOOST_COMPILER_XXX_OR_LOWER for the latter.

To me it looks like a maintenance nightmare, hard to learn, and overly
verbose to use.

>> Nor do I think 
>> 
>>   BOOST_COMPILER_VC <= BOOST_COMPILER_VC71_VERSION_HIGH
>> 
>> is an improvement over
>> 
>>   BOOST_MSVC_VERSION < 070200
>
> I am sorry I can not make you see that and you still want
> programmers to refer to version numbers as numbers.

Life is tough that way, isn't it?  I am sorry that you still want
programmers to use long symbolic macros to label things that are
in fact numbers.

>>>If you are arguing for only using BOOST_WORKAROUND, and never using
>>>a construct like the last one
>> 
>> 
>> Among other things, I am.
>
> Let us suppose that one has workaround code only for BCB6. Currently, because 
> BCB6 encompasses definitions of __BORLANDC__ between 0x560 and 0x564, using 
> BOOST_WORKAROUND one would have to write to be completely correct:
>
> #if BOOST_WORKAROUND(__BORLANDC__, >= 0x560) && BOOST_WORKAROUND(__BORLANDC__, 
> <= 0x564)
> // code
> #endif
>
> whereas with my macros one would write:
>
> #if BOOST_WORKAROUND(BOOST_COMPILER_BORLAND,BOOST_COMPILER_BCB6_VERSION) && 
> BOOST_WORKAROUND(BOOST_COMPILER_BORLAND,BOOST_COMPILER_BCB6_VERSION_HIGH)
> // code
> #endif

Sorry, but that's horrible, IMO.  Aside from it being terribly verbose
and too uniform visually to be easy to read, I'm left wondering what
BCB6 has to do with anything.  I care about the version of my
compilers, not the version of the product that's built around them.
Presumably I could plug any compiler into BCB6.

Also,

  #if BOOST_WORKAROUND(__BORLANDC__, & 0xFF8 == 0x560) // <wink>

But more imporanatly, this scenario of a workaround that is needed for
a range of versions that's closed on both ends doesn't come up often
enough in practice to be very important.

> or even the much more succinct
>
> #if BOOST_COMPILER_BCB6
> // code
> #endif

C'mon, we've been over this.  The _functionality_ of BOOST_WORKAROUND is
important.

> Granted that BOOST_WORKAROUND is more flexible than what I have
> presented, given the practical case above, which I think is very
> prevalent in Boost code, which do you really see as more
> understandable and easier to write ? My point is that while
> BOOST_WORKAROUND is a very good solution in many cases, it is not
> the only solution which should be considered.

Whatever we do, if we're going to change anything we should go through
the code and change everything.  Adding another way to do the same
things in Boost would be much worse than doing nothing at all.

>>>then you are advocating always using specific version numbers. 
>>
>> I don't know what you mean.
>
> I meant that you want the programmer to have to know actual numbers
> relating to preprocessor macros, such as _MSC_VER and __BORLANDC__,

No I don't, and that should be clear from my other posts by now.  I do
think the actual version number of the compiler is important.

>>>In that case you may want to consider at least forms like
>>>BOOST_COMPILER_VC71_VERSION and BOOST_COMPILER_VC71_VERSION_HIGH
>>>useful for your BOOST_WORKAROUND and BOOST_TESTED_AT macros.
>> 
>> I understand why you want it, but am not fond of your proposed names
>> and syntax.
>
> I could care less about the proposed names, as long as the idea were
> acceptable.  However if you do not find the idea acceptable, I will
> not burden you further with arguments for it.

Well, I'm not the only one around; you could convince someone else.
However, I hope I've made my personal position clear enough by now
that I can stop arguing about this.  What about my other suggestion,

     #if BOOST_WORKAROUND(BOOST_GCC,< 3,2,3)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com