From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-03-01 20:24:34
In discussions with the Intel folks about their spoofing of __GNUC__ on
Linux, Clark Nelson pointed out that Boost code should be much more careful
about use of any predefined compiler identification macro, because there is
nothing to prevent any compiler in the future predefining compiler
identification macros used by other compilers. Scary as it is, he is right
AFAICS.
There are two cases I can see for checking a compiler identification macro:
* The code wishes to see if it is safe to use an extension feature such as
a pragma or compiler intrinsic provided by the compiler indicated by the
macro. This is reasonably safe in that presumably the reason the actual
compiler is pretending to be a different compiler is to indicate feature
compatibility with the spoofed compiler.
* The code wishes to apply a workaround for a bug in the spoofed compiler.
This usage is fraught with possible problems. The actual compiler may or
may not have the same bug. If not, useful functionality may be needlessly
disabled or the workaround may not even work.
We deal with _MSC_VER in various compilers by defining BOOST_MSVC if it is
actually the Microsoft compiler.
We deal with __GNUC__ inconsistently by defining BOOST_INTEL rather than
BOOST_GCC.
To be consistent and to prevent being blindsided in the future by other
compilers deciding to spoof one another's macros, perhaps we should define
BOOST_x, where x is the compiler name, for every compiler we have a config
for. And then pointing out the problem in our lib guide for developers.
--Beman