[Development] RFF: nullptr rules

Sergio Martins sergio.martins at kdab.com
Thu Dec 10 17:24:02 CET 2015


On Wednesday, 9 December 2015 14:29:19 WET Thiago Macieira wrote:
> 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.

bool foo = 0;

This is unambiguous, just like your "const char *ptr = 0" example, so "= 
false" wouldn't add value ?



Regards,
-- 
SĂ©rgio Martins | sergio.martins at kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt Experts



More information about the Development mailing list