Gennaro Prota <gennaro_prota@yahoo.com> writes:
As recently come up (again) in the threads
"Comment regarding __GNUC__ spoofing" "[config] Patch for Intel 8.0 + Dinkum lib"
boost library developers have often a need to know the exact compiler in use, but they have no straightforward and easily maintainable way do that. The issue is that they can't just rely on compiler "identification" macros, as predefined by each compiler, because those are not *unique* to each compiler. Two typical cases are __GNUC__, which is defined both by g++ and Intel for Linux, and _MSC_VER which is defined by several compilers. A test for "real" g++, for instance, would look something like
#if defined(__GNUC__) && !defined(__ICL) && !defined...
which is unnecessarily tedious, error prone and hard to maintain. The problem would be solved if the config system exposed a macro for each compiler that it identifies.
There seems to be agreement that this should be done, so please express your opinion about the names you prefer for the macros, or tell why you don't want them. I heartedly ask for *short* names, because preprocessing lines become easily enourmous otherwise (the typical test has the form: #if defined(MACRO_NAME) && (MACRO_NAME <= xx)).
If we define these compiler-identification macros properly (all are defined, most to zero), we can use a BOOST_WORKAROUND macro to eliminate the first condition. That should reduce the pressure to come up with short names, though I see no reason to use names longer than those suggested below.
Currently, there are 16 config files in boost/config/compiler/ but we don't need so much macros immediately. So I just propose the following (other ones can be added on an "as needed" basis):
BOOST_BORLAND BOOST_COMEAU BOOST_GNU (1) BOOST_INTEL BOOST_MSVC (2)
IMO we should try to do this in a big sweep if practical. I realize we'd touch a lot of code, so it may not be, but, but I think we have too many legacy compiler checks, using different conventions, in our source.
---- Notes: (1) since the other macros employ the name of the producing company, rather than the name of the compiler, BOOST_GNU seems more consistent than BOOST_GCC (though, of course, GNU is not a "company") (2) this is inconsistent, but it already exists. Maybe BOOST_MICROSOFT, or BOOST_MS, could be provided as a synonym.
I think we should use names of compilers rather than companies. Someday we may have several C++ offerings from the same company. -- Dave Abrahams Boost Consulting www.boost-consulting.com