Re: [boost] Defining compilers suggestion

From: Edward Diener (eddielee_at_[hidden])
Date: 2005-07-13 11:25:04

David Abrahams wrote:
> Edward Diener <eddielee_at_[hidden]> writes:
> 
> 
>>one could create a series of macros, let us say for VC71, like this:
>>
>>// These are always defined and included in a header file at the top of 
>>select_compiler_config.hpp
>>
>>#define BOOST_COMPILER_VC _MSC_VER
> 
> 
> It's a lot more complicated than that, unfortunately, because many
> other compilers define _MSC_VER to "act compatible" with VC++.

Yes, I understand that. In that case it should be:

#define BOOST_COMPILER_VC 0

in the in the header file to be included at the top of select_compiler_config.h and

#define BOOST_COMPILER_VC _MSC_VER

only in the header file included at the top of visualc.hpp whern that is the 
compiler selected.

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.

> 
> 
>>You could now say:
>>
>>#if BOOST_WORKAROUND(BOOST_COMPILER_VC,BOOST_COMPILER_VC71_VERSION)
>>// code
>>#endif
>>
>>or, in a different situation:
>>
>>#if 
>>BOOST_WORKAROUND(BOOST_COMPILER_VC,BOOST_TESTED_AT(BOOST_COMPILER_VC71_VERSION_HIGH))
>>// code
>>#endif
>>
>>or, in a different situation:
>>
>>#if BOOST_COMPILER_VC71 // and any other combinations you like
>>// code
>>#endif
> 
> 
> 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.

> 
> 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.

> 
> 
>>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

or even the much more succinct

#if BOOST_COMPILER_BCB6
// code
#endif

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.

> 
> 
>>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__, for a particular version 
of a particular product. I want to bury the need to have this knowledge as much 
as possible while realizing it may still be needed for some situations. I 
believe, from looking at the workaround code I have seen in Boost, that the 
number of times such knowledge is actually needfed for workarounds is minimal 
compared to the knowledge that a particular workaround is needed for a 
particular specific version or specific versions of a compiler.

> 
> 
>>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. Hopefully it will at least have thrown out a few useful 
ideas for the future which make specifying workarounds for non-compliant 
compiler/versions easier to do. Of course it is my fervent hope that fewer 
workarounds will be needed as compilers pursue C++ standard compliancy.