[Development] Fwd: RFF: nullptr rules

Richard Moore rich at kde.org
Wed Dec 9 18:23:20 CET 2015

Resending from the right address.

---------- Forwarded message ----------
From: Richard Moore <richmoore44 at gmail.com>
Date: 9 December 2015 at 17:22
Subject: Re: [Development] RFF: nullptr rules
To: "development at qt-project.org" <development at qt-project.org>

On 9 December 2015 at 15:14, Marc Mutz <marc.mutz at kdab.com> wrote:

> - 0 as a nullptr constant is banned except in tests testing APIs so
>   we don't accidentally require nullptr (ie. all tests should use 0, not
>   nullptr, as far as it makes sense)

​This seems pretty arbitrary to me, and would lead to inconsistency with
APIs that ​predated this rule. I can't say I'm in favour.

> - clang-modernize is used to convert all uses of the null pointer constant
> to
>   nullptr, incl. examples, excl. tests and 3rdparty

​Won't this just add noise and make forward porting bug fixes harder? I
don't see it gains much.​

> - APIs that require the use of nullptr for disambiguation are discouraged,
>   but may be acceptable to be decided on a case-by-case basis.

​Makes sense​

> Arguments in favour:
> - it's the C++ way of writing the null pointer constant these days
> - we need to use it in headers, anyway, to allow people to use
> -Wzero-as...,
>   and it makes no sense to have two sets of rules for headers and impl

​There's nothing that says we need to allow people to use that warning, and
nothing stopping us disabling it for our headers, so this is a

> - it can disambiguate code and prevent accidents

​I'm not convinced about this for sane APIs.​

> - in some situations, it makes code easier to understand (:
> m_foo(nullptr)).
I don't see any difference from 0 here to be honest, but perhaps that's
just me.​

> Arguments against:
> - it's uglier than "0", and more to type

​Definitely, also:​

- ​It will also make forward-porting​

​bug fixes and merges harder.​

- If the automated change you suggest was done then the history would be (a
little) less useful.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20151209/ca414f33/attachment.html>

More information about the Development mailing list