David Abrahams wrote:
Edward Diener <eddielee@tropicsoft.com> 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.