Subject: Re: [boost] [PREDEF] Review for the Boost.Predef library by Rene Riviera
From: Bjorn Reese (breese_at_[hidden])
Date: 2012-02-29 12:55:38
On 2012-02-28 08:09, Rene Rivera wrote:
> I guess that depends on the developers. The reasons the macros are
Not really. There are many projects that use the pre-defined compiler
macros, and all that I have seen leave the non-pertinent platform
In most cases the projects only need to check for the presence/absence
of a platform macro, and only in more special cases do they need to
check the version number. Boost itself may be an exception, but if
Boost.Predef is going to be available to everybody, then it should be
optimized for the common case.
> #if defined(_some_compiler_) && (_some_compiler_ < 123)
If you want a compact syntax then use:
#if (_some_compiler_ - 0 < 123)
> Which is the distinction between *actual* and *emulated* I mentioned in
> the other post tonight.
However, in that reply you mentioned the possibility of added predefs
for the emulated compiler. I do not think that is needed as the emulated
stuff is only enabled to gain access to extensions in header files that
assume that only gcc supports those extensions.
This use of the macros is really a bad design. A better design has been
opted by Posix, where there are two sets of macros:
_POSIX_VERSION : Tells you the actual version being used.
_POSIX_SOURCE : You tell the compiler to use a specific version.
But I am digressing...
> That doesn't follow from the argument. It is possible to instead have
> the clang.h file both define the Clang compiler, and undef all the other
> *emulation* predefs. Or more useful, define separate emulation predefs
The point that I was trying to raise was that with separate files you
would have to use other macros besides the platform you want to check
for in the single file (e.g. either gcc.h would have to use __clang__
or or clang.h would have to use __GNUC__). So since you have a
dependency between these platforms, the idea of keeping everything
neatly separated in indidual files is diluted. This was only a minor
point though. File access and speed of inclusion, as mentioned by
several people, is still the major issue with the separate files.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk