[ ... ]
Let's look at the files in boost/config/compiler/, specifically the
visualc.hpp and gcc.hpp . They contain all the information on what the
compiler is and is not capable of.
Dedicated to VC7, there are 20+ macros defined in visualc.hpp that are
named in the following fashion:
#define BOOST_NO_XXXX
Please excuse me for not listing them here.
I'll excuse you, but I won't let you off the hook. I'm going to list at
least a couple here, in the hope that you might learn from it.
Back in 2003, the contemporary gcc compiler was gcc3. The gcc.hpp
contains only 4 macros named like the above that are dedicated for
gcc3.
Now let's see what's happending now (in 2008).
The visualc.hpp indicates that every version of VC till VC9 all
recieved macros named like BOOST_NO_XXXX , though the number is far
less than that of VC7.
Quite true.
While in the gcc.hpp file at the section for gcc4, I didn't see a
single BOOST_NO_XXXX macro, but quite a few BOOST_HAS_XXXX macros.
Not too surprising. But now let's take a look at some of those macros
and figure out what they mean.
For our first example, let's consider:
# define BOOST_NO_INTEGRAL_INT64_T
VisualC.hpp. This means the compiler doesn't define a type by the name
of 'long long' -- but then, C++ doesn't _allow_ a conforming compiler to
define a type named long long. A bit later in the same file we find:
#if (_MSC_VER >= 1200)
# define BOOST_HAS_MS_INT64
#endif
#if (_MSC_VER >= 1310) && defined(_MSC_EXTENSIONS)
# define BOOST_HAS_LONG_LONG
#endif
In other words, 1) VC++ really does have an integral type of 64 bits --
but it's given the name "__int64" instead of "long long". Since
"__int64" is in the implementor's name space, this is a conforming
extension.
gcc, by contrast, uses the name "long long" -- which isn't exactly a
terrible extension, given that it's the accepted name for a 64-bit
(minimum) type in C99 and the current draft for C++ 0x. OTOH, according
to the current C++ standard, code that uses 'long long' simply isn't
conforming. IOW, what we're seeing is an instance where VC++ conforms to
the standard, but gcc does NOT.
In the end, it comes down to this: most of the Boost contributors use
gcc as their primary compiler, so they've picked gcc as their baseline.
They don't update the baseline _every_ time the compiler is updated, but
even so, the BOOST_HAS_XXXX and BOOST_NO_XXXX macros are NOT really
telling you how different the compiler is from the standard -- they're
really telling you how different the compiler is from the version of gcc
they've chosen as their baseline.
Once you realize that, it's hardly surprising that reasonably recent
versions of gcc don't require any BOOST_NO_XXXX macros, and really
recent versions just add a few BOOST_HAS_XXXX macros to cover features
added to the compiler since the version they're using as the baseline.
Older versions of gcc have a few BOOST_NO_XXX macros, but (again) it's
not really much of a surprise that older versions of gcc are still
pretty similar to newer versions of gcc, whereas other compilers tend to
be somewhat different from gcc.
If you look (for example) in common_edg.hpp, you'll find that it _does_
define some BOOST_NO_XXXX macros -- even though EDG has led the market
in terms of language conformance pretty much since the day it came onto
the market.
By the way, both gcc and icc provides experimental c++0x features in
their most recent releases. Does VC9 offer any of those?
Yes, though only a few. There's (quite) a bit of tension when it comes
to adding new features though. People experimenting with new language
features want the compiler to change as quickly as possible, adding
every new feature as soon as anybody even thinks of it. People
maintaining production code want the compiler to stay exactly the same
_forever_, never changing anything that could possibly break any
existing code.
Think for a moment, and you'll realize that to Microsoft it's _far_ more
important to ensure that (for example) all the code in Windows and
Office continues to work than it is to claim they were the first to
support feature XXX (that was informally accepted in one committee
meeting, but formally rejected in the next one).
gcc (for one example) is in a rather different position. First of all,
though quite a bit of code depends on gcc, the gcc folks aren't going to
get fired if their new revision breaks existing code or isn't binary
compatible with the previous version (in fact, gcc has done both quite
regularly...)
Don't get me wrong: that doesn't mean gcc has NO interest in stability
_or_ that Microsoft never adds new features -- but it does mean that for
Microsoft, new features must be justified, not just added because
somebody thought they'd be cool. That's going to be cost justification
-- how much does it cost to implement, how much to get code to work with
it again, and how much does having it save over the next X years.
For example, despite being far behind in some areas, MS was one of the
_very_ first vendors to ship working namespace support. Given their use
of large teams and lots of existing code, that strikes me as about as
surprising as the sun rising in the morning.
.