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