Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-03-22 19:05:48

Gennaro Prota <gennaro_prota_at_[hidden]> 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):

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

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

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