[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