Boost logo

Boost :

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-08-17 06:25:30


Daryle Walker wrote:
> I don't understand what problem this change is going to solve. If a
> compiler has a strict C++-1998 mode, then supporting "(unsigned) long long"
> anyway is sort-of a disfeature. Maybe we should just have the headers
> assume that the double-long types are absent. (The changes don't affect
> compilers that don't have the double-long types at all, right?)

The -std=c++98 option (also called -ansi) causes gcc to become standards
compliant. Without it, gcc implements a nonstandard "GNU" dialect of
C++. People who desire standards conformance and better compile-time
checking often use this option. For many C++ projects, all files are
compiled with it along with the more familiar -Wall.

As a side effect, it causes errors to be generated when the long long
typename is used unadorned. (I've heard this might be changed in the
future, as long long might not actually conflict with the standard.)
All of the support is still there, including from the standard library.
 You can still use long long provided you add __extension__, as
documented in the manual.

To further clarify, -std=c++98 does not disable long long, and in
general, does not disable extensions. It just means you need to use a
special syntax when you use the long long type name.

So, to answer your question, this patch makes Boost compile for people
who use the very common practice of compiling with -std=c++98 (or
-pedantic). While it would be possible to just disable long long
support on GCC -std=c++98 is specified (and not support -pedantic at
all), this would be very unfortunate, as this type is still supported in
this mode, and users still expect it to work correctly and be supported
by libraries.

-std= Documentation:
http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/C-Dialect-Options.html
long long in libstdc++:
http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html

Aaron W. LaFramboise


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk