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

[Marc Mutz]

On Wednesday 11 February 2015 18:02:53 Matthew Woehlke wrote:
> On 2015-02-11 04:18, Marc Mutz wrote:
> > On Wednesday 11 February 2015 00:37:18 Matthew Woehlke wrote:
> >> Marc, I'm not sure if you're arguing for or against nullptr :-)...
> >
> > 
> >
> > Then I agree with André; you need to start reading mails (threads)
> > before  responding :)
> 
> Will someone please explain to me why you think I'm not?

It's either that or

> Is my irony detector broken?

this.

I was replying to André's question "can't you [..] wait until nuklptr is 
available?" with No.

I thought that was obviously pro-Q_NULLPTR :)

> >> (Oh... and 'auto ptr = 0;' does not give you a pointer. Not relevant to
> >> Qt, but just saying...)
> >
> > 
> >
> > While true, this is semantics that we can't rely on in Qt atm.
> 
> (Ahem: "[this is] not relevant to Qt". Speaking of irony, I guess I'm
> not the only one that can't keep the entire thread straight...)

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).

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++).

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*). foo(Q_NULLPTR) may be ambiguous, 
call the int overload or the void* overload. Again, we can't rely on nullptr 
semantics when using Q_NULLPTR. We can only hope to catch some bugs and 
otherwise improve readability by using it (but the later, as we've seen is 
controversial).

> > nor can it be relied on that Q_NULLPTR doesn't convert to an 
> > integral type.
> 
> True for a given build. However, there is a fair chance that some other
> (C++11) build will break in case of such code, increasing the chances
> that someone will notice any issues of this nature.
> 
> > The latter is esp. interesting, as I believe some compilers 
> > implement NULL to be nullptr-like even in C++98 (and Q_NULLPTR is NULL if
> > it's  not nullptr), so you may benefit even in C++98 by using Q_NULLPTR
> > instead of 0. But you can't rely on that.
> 
> This too :-).

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions