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