[Development] RFF: nullptr rules

Thiago Macieira thiago.macieira at intel.com
Wed Dec 9 23:29:19 CET 2015


On Wednesday 09 December 2015 22:47:51 Marc Mutz wrote:
> >         const char *ptr = 0;
> 
> What we agreed on was for Q_NULLPTR.
> 
> Some developers back then were complaining that the *macro* is ugly, and
> that by 5.7, we would be able to use the real thing and didn't want the
> double conversion 0 -> Q_NULLPTR -> nullptr.
> 
> The agreement back then also was not to rely on the disambiguating features
> of nullptr, because Q_NULLPTR might be 0.
> 
> Now we can use the real thing. With real nullptr semantics.

True.

I'd like to propose this:
 a) no massive replacement or clang-modernize, for the reasons Richard pointed 
out
 b) which means existing zeroes continue in sources and private headers
 c) which means no -Werror=zero-as-nullptr outside of headersclean

New code should use nullptr where it improves readability.

Changes to existing code can update to use nullptr.

But I don't think we should mandate use of nullptr everywhere. Where it's 
unambiguous, it doesn't add value.

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




More information about the Development mailing list