Re: [boost] Defining compilers suggestion

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.