[Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Matthew Woehlke]

On 2015-02-11 15:38, Marc Mutz wrote:
> On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote:
>> (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to
>> Qt, but just saying...)
> 
> You said auto ptr = 0 doesn't give you a pointer. By extension, I thought you 
> were saying that auto ptr = nullptr does (and it does, in a way).

Right (well, a nullptr_t anyway which behaves the same as an in-place
'nullptr'; in particular, can be implicitly converted to a pointer, and
*cannot* be implicitly converted to a numeric type).

> But for Q_NULLPTR, auto ptr = Q_NULLPTR may be deduced as nullptr_t on a c++11 
> compiler, int (NULL = 0) on others, long (NULL = 0L) on yet other, and void* 
> (NULL = (void*')) on the rest (yes, not all of them are valid in C++).

Good point. You're right that Q_NULLPTR "isn't adequate" here. (OTOH,
the range of compilers / versions that support C++11 'auto' but *not*
C++11 'nullptr' or e.g. something like __null is not so great.)

> So I maintain that we can't rely on nullptr semantics here as long as we use 
> Q_NULLPTR. Same for foo(int) vs. foo(void*).

Right. Qt is not at a point where it can write API that relies on the
existence of nullptr/nullptr_t. Overloading in particular is a no-go.
Q_NULLPTR is still useful because *some* builds will break if you try to
pass a Q_NULLPTR where only an integer type is accepted, but not *every*
build will catch such errors even using Q_NULLPTR. (I think we're in
agreement on this point?)

-- 
Matthew