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.m...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development