On Jun 28, 8:06 am, Jerry Coffin <jcof...@taeus.comwrote:
In article <a59bbc9a-36f8-48eb-8a6d-f3804f1ee185
@c65g2000hsa.googlegroups.com>, huil...@gmail.com says...
[ ... ]
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 g++ still doesn't, unless you request extensions. (At least
as of version 4.2.1, using long long with -Wall -pendantic
causes an error.)
VC++ 2005 does support long long (although I presume that there
is an option to turn it off, for conformity's sake). But as you
say, it's not (yet) C++. When all is said and done, of course,
long long is an abomination, adopted by C99 because it was
existing (bad) practice, and adopted by C0x because it was in
C99. The C90 standard had provisions for creating new types
(and new anything in the language): use a keyword whose name
starts with __ or _[A-Z]. Technically, there were really only
two reasonable choices in C90/C++98 for a 32 bit compiler to
offer a 64 bit type: make long 64 bits, or define a new type
with a name like __int64.
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.
Gcc used the name "long long" because most other Unix compilers
had started using it. Gcc did not come up with it; their
motivation is purely compatibility with stupidity of other
compilers. And g++ don't support it when invoked with
extensions turned off.
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.
And where VC++ made a technically intelligent decision, and the
Unix C/C++ compilers didn't.
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.
I don't know about that, but historically, the VC++ which was
current when much of the older Boost stuff was developed was
6.0, which was pretty weak with regards to macros. So the habit
developed to use macros to work around problems in VC++, but to
try to make the code really portable for other compilers.
[...]
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.
And people developing new code prefer that their compiler not be
the first to adopt new features---the first implementations are
always the poorest. Let others do the experimentation, and once
it's well established how to make it work, then evolve.
For the rest, I think you pretty much summarized the problems
and the trade offs involved between stability and new features.
I just might add that in recent years, g++ has moved more and
more in the direction of stability---in other words, has become
more and more like Microsoft, Sun CC et al. For those of us who
use the compiler in a production environment, this is a good
thing.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
