Using nullptr instead of Q_NULLPTR

[Thiago Macieira]

On Friday 14 August 2015 14:34:49 Jarosław Staniek wrote:
> I also think we agree that anything other than 0 is good for readability
> and  readability should be the priority.

Note that the Qt 5.7 policy still allows and even asks for use of 0 as null in 
some places. The policy is:

 * always use nullptr in public headers. No exceptions.
 * use nullptr or 0 in non-public headers or regular sources so readability is 
   good. There's no point in using nullptr where 0 is obviously a null 
   pointer, like:
	char *s = 0;

> Then, there's the consistency factor -- a reason to cover the topic of null 
> pointers in the guide. I find neither Qt is consistent in what to use, Qt
> is not an example here then.

The policy above applies to Qt 5.7. For 5.6, only the first part applies and it 
needs to be Q_NULLPTR.

> In the worst case if someone calls us too modern, e.g for embedded
> projects,  we'd be able a macro to ECM kdecompilersettings that defined
> nullptr back to 0 (or is this already supported by cmake/etc.?)

Don't do that. If you use nullptr, there's no going back to zero because it's 
not the same. You've irrevocably locked yourself into requiring a compiler 
that supports it.

> PS: A Krazy check checking for usage of NULLs and Q_NULLPTR would be
> lovely.  Checking the use of 0's isn't easy, right?

-Wzero-as-null-pointer-constant

Qt headers should pass that starting with 5.6.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358