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

Thiago Macieira thiago.macieira at intel.com
Thu Jan 8 23:33:34 CET 2015


Hello

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.

Note that Qt still compiles with C++98, so you can't use Q_NULLPTR for 
disambiguation. For example, the new QIODevice::readLine overloads

	QByteArray readLine(qint64 maxSize);
	bool readLine(QByteArray *line, qint64 maxSize = -1);

In C++11, you could write
	if (dev.readLine(Q_NULLPTR))	// read a line and discard

But the code above would be ambiguous in C++98, so you can't use it.

Special: update code using Q_NULLPTR as you would update whitespace.

 * 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

 * Q_DECL_EQ_DELETE - strongly encouraged, use with care

Let's the compiler print an error instead of allowing a linker error for an 
unresolved symbol.

 * Q_DECL_CONSTEXPR / Q_DECL_RELAXED_CONSTEXPR - strongly encouraged

Use where it makes sense. If possible, use the C++11 restricted constexpr as 
we have still too few compilers with C++14 relaxed constexpr support (Clang 
3.5, GCC 5), but feel free to use Q_DECL_RELAXED_CONSTEXPR when there's benefit 
for constexprness but impossible to solve in C++11

 * Q_DECL_FINAL - optional, use with care

There's a small benefit in optimisation by devirtualising calls. Use it with 
care.

Use in public classes is discouraged, since people can compile with a C++98 
and derive / override what they shouldn't.

 * Q_DECL_OVERRIDE - required in new code, don't add to old code

Always add Q_DECL_OVERRIDE for any override in new classes you write. This 
supersedes the need for the "virtual" keyword -- add it or not, it's up to 
you.

DO NOT add to existing classes, including for new overrides to existing 
classes. Clang 3.6 has a new warning about inconsistent use of this keyword, 
so adding to one place requires adding to all overrides in that class. 
Therefore, this needs to be done fully in each class and that's not a 
"whitespace correction" error.

 * Q_CONSTEXPR - use only where required

You probably don't need this. You'll need it when accessing const data from a 
Q_DECL_CONSTEXPR function. Otherwise, you won't need it.

You could use this to create a static-initialisation-time const variable of a 
non-POD type, but since our sources still compile in C++98 and we still have a 
rule against non-POD statics, you should not do this.

 * Q_DECL_NOTHROW / Q_DECL_NOEXCEPT - strongly encouraged

To public functions (all modules); any function in modules compiled with 
exception (QtCore, QtXmlPatterns, QtConcurrent).

You probably want Q_DECL_NOTHROW instead of Q_DECL_NOEXCEPT.

Do not add to functions that:
 * allocate memory
 * call functions that may throw, especially user functions
 * call POSIX cancellation points
 * have narrow contracts -- that is, you could conceivably add a Q_ASSERT on 
   input parameters

If the function is an inline template function and the exception depends on 
the template argument, use Q_DECL_NOEXCEPT_EXPR.

Non-C++11 but also useful:

 * Q_DECL_{PURE,CONST}_FUNCTION - encouraged

A pure function is a function that will return the same value if called twice 
with the same parameters. Pure functions are allowed to read from pointers 
passed to it, including the "this" pointer. Pure functions are not allowed to 
have observable side-effects (rule of thumb: no writing to dereferenced 
pointers or to global variables).

A const function is a function that is pure and does not dereference any 
pointers.

Quite by definition, const and pure functions cannot return void. Any such 
calls would be discarded by the compiler.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list