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

[Matthew Woehlke]

On 2015-01-08 17:33, Thiago Macieira wrote:
> I think it's time to institute a policy that we should fix our sources to use 
> the new C++11 keywords. I'd like to propose the following.
> 
> Policy per keyword:
> 
>  * Q_NULLPTR - strongly encouraged
> 
> Use it whenever your literal zero is a null pointer. You can leave it out when 
> it cannot be mistaken for a zero and it would otherwise make the source code 
> harder to read.

Jumping in a little late, but... please don't add this exception. If you
mean nullptr, *write nullptr* (or Q_NULLPTR as the case may be).
*ESPECIALLY* in macros.

With 4.x it was not possible to use -Wzero-as-null-pointer-constant with
Qt projects due to use of '0' in Qt headers. Even with -isystem, things
like Q_OBJECT would produce so much noise as to make the warning
useless. (Also IIRC default arguments have similar problems.) If you're
going to seriously use Q_NULLPTR, IMHO it should be a goal that Qt can
compile with -Werror=zero-as-null-pointer-constant. That means *no
exceptions*.

(@Andre, and is why I *really, really hope* that Qt *will* use Q_NULLPTR
and not 0, at least in headers. What you do in your own private code is
your business, but refusing to use nullptr in headers is penalizing your
users also.)

>  * Q_DECL_EQ_DEFAULT - really discouraged
> 
> I can't think of any case where you could use this and let the code still 
> compile in C++98, so don't use it

I'd actually like to see this used where possible and sensible, as the
compiler may be able to optimize better (or it can make POD types that
otherwise wouldn't be POD).

You can use it like:

  class QFoo { QFoo(const QFoo&) Q_DECL_EQ_DEFAULT; }
  #if // '= default' not supported
  QFoo::QFoo(const QFoo& other) { ... }
  #endif

...that is, provide a definition conditional on Q_DECL_EQ_DEFAULT
expanding to empty. (This will also make it easy to rip out the old code
if/when C++11 becomes a requirement for Qt.)

-- 
Matthew