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

[Matthew Woehlke]

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