Re: [boost] Another patch for long long in gcc -std=c++98

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-08-17 19:47:31

John Maddock wrote:
>>>As a side effect, it causes errors to be generated when the long long
>>>typename is used unadorned.
>>
>>This isn't strictly true. "long long" will be accepted without any
>>diagnostic, even with "-ansi -Wall", it is "-pedantic" that causes it to
>>be rejected. I tested this on Linux and FreeBSD, with 2.95 and 3.[0345],
>>and the doc links you gave confirm it:
> 
> That's right, and if you supply -Wno-long-long as well, then you can compile
> with -pedantic -ansi -Wall with no problems.

I don't know why I had assumed that this had something to do with
-std=c++98 rather than -pedantic.  Sorry for the misinformation.

Despite these comments, I still beleive that it is valuable to allow
Boost to compile cleanly with -pedantic without having to specify
-Wno-long-long.  In the name of encapsulation, the main program/project
should not have to disable warnings (that the developers may well be
interested in) because the implementation of a library might need the
warning disabled to compile cleanly.

The reason to reject this sort of patch would be that changing all
instances of long long in headers would be too intrusive.  Given that
long long is not yet standardized in any C++ standard, I do not think
that it is inappropriate to access it through a proxy type name, and
that it would be valuable to allow Boost to work seamlessly with GCC
diverse option sets (and possibly other compilers that have a similar
situation).

Is there a policy or rationale on modifying Boost code to eliminate
compiler warnings?

Since I do not want to use -pedantic but not specify -Wno-longlong--I
really do want the 'pedantic' warnings with unadorned extensions like
long long warned--it is likely that I (and perhaps many other people who
use GCC) will retain something like this patch locally if it is deemed
inappropriate for Boost.  This would be unfortunate.

Aaron W. LaFramboise