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
>>#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
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:
>>or, in a different situation:
>>or, in a different situation:
>>#if BOOST_COMPILER_VC71 // and any other combinations you like
> 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
> 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__,
whereas with my macros one would write:
#if BOOST_WORKAROUND(BOOST_COMPILER_BORLAND,BOOST_COMPILER_BCB6_VERSION) &&
or even the much more succinct
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk