Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-07-10 09:12:17

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:

Not sure why you'd want to do that. Then you only get a binary value
for BOOST_COMPILER_SOME_COMPILER. I'd rather havea composite version

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

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


Whereas we'd like to simply write


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

> 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

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at