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

[Thiago Macieira]

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