Using nullptr instead of Q_NULLPTR
thiago at kde.org
Fri Aug 14 21:34:28 BST 2015
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
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?
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
More information about the kde-core-devel