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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
