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