On Friday 14 August 2015 04:07:41 Thomas Lübking wrote: > We could just detect the compiler, and in need define nullptr 0x0, look the > other side and hope for the best (ie. anybody on modern compilers anyway > and nobody actually making use of std::nullptr_t atm. but just of the > keyword) - not very nice, but better than breaking compilation(?) and not > as invasive.
It's not the same thing. First of all, it can't be a variable, it would have to be a macro. Second, a literal zero can be cast to boolean, integrals and floating point, but nullptr can't. That's the whole reason why nullptr exists in the first place. Q_NULLPTR isn't nullptr: when you use it, you acknowledge that it may be a zero and thus won't resolve ambiguities when calling overloads -- or, worse, will call the wrong overload (the one with int instead of the one with a pointer). Defining a macro for nullptr is dangerous... My recommendation: it's broken now so leave it. Fix it if someone complains, but otherwise just leave it. In one year's time, the discussion will be moot. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358