From: Edward Diener (eddielee_at_[hidden])
Date: 2005-07-10 12:31:07
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.
> I'd rather havea composite version
> number.
I would rather know whether some compiler is being referred to or not.
>
>
>>where SOME_COMPILER might be VC71,GCC40 etc.
>>
>>Then in code one could see:
>>
>>#if defined(BOOST_COMPILER_VC71) etc.
>>
>>rather than the less understandable
>>
>>#if defined(MSC_VER == nnnn) etc.
>
>
> Actually we have BOOST_MSVC. The only reason we'd test _MSC_VER is
> for those cases where we want to catch *all* compilers that emulate
> VC++ (e.g. for #pragma once).
Does BOOST_MSVC referring to all versions of MSVC ? I wanted something
easy which refers to particular major version of particular compiler
toward which Boost is targeted.
>
>
>>I would just like to see more readability in the Boost code regarding
>>compiler workarounds. I am also aware their is a workaround macro, but
>>even that deals in compiler preprocessor tags rather than a more
>>readable compiler version. I am aware that many workarounds have to deal
>>with versions before or after a certain version number but even that can
>>be made more readable by macros which tell one the actual compiler which
>>is involved.
>
>
> We've had a plan for a long while to introduce a #define for each
> compiler vendor. One reason to do that is that many preprocessors
> have a (often very useful) warning that barks whenever you do a
> comparison test on a symbol that isn't #defined. The standard says
> it's legal to test un-defined symbols (they are treated as zero), but
> that often masks programmer errors. Right now, to avoid the warnings
> for most symbols, you have to write:
>
> #if defined(COMPILER_SYMBOL) && BOOST_WORKAROUND(COMPILER_SYMBOL, whatever)
> ...
> #endif
>
> Whereas we'd like to simply write
>
> #if BOOST_WORKAROUND(COMPILER_SYMBOL, whatever)
> ...
> #endif
>
> (and many of us already do, which leaves some users with lots of
> annoying warnings).
>
> So we'd like to have a suite of symbols like BOOST_GCC_VERSION, etc.,
> that are always #defined, and are zero if the compiler in question
> isn't being used.
Is there a list of general compiler/versions which Boost supports. On
Windows I know of Visual C++ 6.0, 7.0, 7.1, and 8.0, and Borland BCB5
and BCB6. I am not sure of which _MSC_VER corresponds to each of the
compilers although I can test it out for ther ones I have on my machine.
Is there a comprehensive list kept anywhere.
>
>
>>I realize I am just a reader of Boost code and not a Boost developer but
>>I think this suggestion would make for a little more readable code in
>>its own small way.
>
>
> I agree! I suggest you prepare a patch for the config library that we
> can use in Boost after 1.33.0
>
If I can get a comprehensive list of compiler/versions and their
corresponding preprocessor symbols I will be glad to do it. I can find
out the appropriate information for Microsoft and Borland on Windows
easily enough myself.