On 09-Dec-15 16:14, Marc Mutz wrote:
in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler, but
there are no guidelines as to its use in the coding conventions (to the extent
they need to be in there).
There are also no guidelines for every other language feature, and I
doubt that we need those. Everything that's not controlled by rules is
controlled by common sense, which I trust this community has.
I propose the following, based on Thiago's proposal from January this year,
considering the new situation that we now require nullptr support in the
compiler:
- 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)
What is the advantage apart from fixing the edge case of having
void foo(int)
and
void foo(Blubb *)
?
- clang-modernize is used to convert all uses of the null pointer constant to
nullptr, incl. examples, excl. tests and 3rdparty
This just adds pointless noise to the history. I see no value in it.
- compilers that have it, will have -Wzero-as-nullptr-constant added during
headersclean[0]
I can see value in enforcing nullptr in public headers.
- APIs that require the use of nullptr for disambiguation are discouraged,
but may be acceptable to be decided on a case-by-case basis.
I agree.
- Accidental (ie. non-apidox'ed) reliance on nullptr for disambiguation is
always an error. To this end, tests should continue to use 0, not nullptr.
- if (!foo) vs. if (foo == nullptr), if (foo) vs. if (foo != nullptr):
author's prerogative[1]
[0] I'd prefer "when building Qt", but realise that we'll have problems with
upstream libs
[1] I prefer the short form, but I don't think we'll gain a consensus here, so
let's not even try
So why do you try yet?
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
- it can disambiguate code and prevent accidents
Yes, it can. In edge cases. Let's use nullptr for those.
- in some situations, it makes code easier to understand (: m_foo(nullptr)).
So nullptr is easier to understand, because assigning 0 to a pointer
variable didn't make clear that it now contains a null pointer?
If there's need to signify using m_foo(nullptr) that m_foo is a pointer,
then m_foo is maybe a bad name and should be fixed.
There are very few cases where nullptr actually prevents errors. Let's
use it there. And if you think it's pretty and fits your style, use it.
But do not enforce it just because of its mere existence.
BR,
Joerg
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
