On Wednesday 11 February 2015 15:54:40 Matthew Woehlke wrote: > 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).
True, but that's not the point here. The only value allowed for nullptr_t is nullptr, which is why any nullptr_t can be converted to any pointer. However, the point here is: auto ptr = nullptr; ptr = &something; // error! void *ptr = nullptr; ptr = &something; // ok > > 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.) What's the type of ptr in? auto ptr = __null; Hint: GCC prints this warning: warning: converting to non-pointer type ‘long int’ from NULL [-Wconversion- null] > > 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. It can be done, with some effort, for non-public API (that is, not ABI- binding): https://codereview.qt-project.org/100076 specifically https://codereview.qt-project.org/#/c/100076/4/src/corelib/kernel/qmetatype_p.h > 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?) Only if we build with -Werror -- which we do, in the compilers that support __null. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development