On 26 August 2011 18:13, Jonathan Wakely wrote: > On 26 August 2011 14:09, Paolo Carlini wrote: >> On 8/26/11 2:59 PM, Rainer Orth wrote: >>> >>> Hi Paolo, >>> >>>>> Ok for mainline if bootstraps pass? >>>> >>>> Not a comment strictly about this patch, but why we have things like #if >>>> __cplusplus>= 199711L anywhere? For sure the library is not supposed to >>>> be >>>> used together with old C++ front-ends. >>> >>> I thought about this myself, but at least the overloads are only present >>> with __cplusplus>= 199711L. >> >> I don't understand: isn't __cplusplus now *always* >= 199711L? Or you want >> to protect vs the user undefining __cplusplus and then defining it to a >> different value?!? I don't have the Standard at hand (in theory I'm in >> vacation ;), maybe Marc can help, but I don't think it's legal, is it? > > [cpp.predefined]/3: > > "If any of the pre-defined macro names in this subclause, or the > identifier defined, is the subject of a #define or a #undef > preprocessing directive, the behavior is undefined." >
More specifically, __cplusplus is ***NOT*** a feature-test macro like _POSIX_SOURCE that can be set by users to request different language standards. Setting __cplusplus will have no effect on the front-end, but might confuse the library (or other third-party headers) just as using -D__GXX_EXPERIMENTAL_CXX0X__ without -std=g++0x will cause big problems, because the front-end will be using -std=c++98 mode but the library will think C++0x support is enabled. Doing this will cause pain. If there is ***any*** maintenance overhead involved in "supporting" users who try to redefine __cplusplus then I think it's a mistake. I'm certainly not going to think of the effects on those users when I make changes to the library.
