On 2015-02-11 16:21, Thiago Macieira wrote: > 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
True, but if you know what type you want (e.g. 'void*') you should be specifying it explicitly. I was thinking of a case where you are going to pass nullptr to something, but for some reason you want to put it in a local variable first. (Admittedly, it's a stretch.) I think we've gone just a bit off topic for something I said up front wasn't very interesting :-). > 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] Huh :-). So much for hoping that __null == nullptr in C++11 mode. (I'm not going to claim to understand the intricacies of __null...) >> 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 Well, sure; I was intentionally ignoring the case of a library work-around to provide a nullptr_t. (Pedantic: shouldn't that have a conversion operator?) >> 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. Um... do you not have *any* C++11 builds? If Q_NULLPTR == nullptr (which I assume it is in C++11?), and you try to pass Q_NULLPTR to something that wants an integer type, you'd better get a compile error, because such a conversion is not allowed by the C++ standard. (At least gcc-c++-4.8.3-7.fc20.x86_64 correctly rejects this.) -- Matthew _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
