nullptr for NULL pointers

[Julien Chaffraix]

Hi everyone,

our coding style still mentions using 0 for NULL pointers:

In C++, the null pointer value should be written as 0. In C, it should
be written as NULL. In Objective-C and Objective-C++, follow the
guideline for C or C++, respectively, but use nil to represent a null
Objective-C object. [zero-null]

However it seems that new code is using nullptr more frequently than 0
as it's easier to read and add some type safety.

Any objection to changing the previous rule to require using nullptr for C++?

Julien

[Ravi Kasibhatla]

I had asked the same question around 4-5 months back - should we replace all 0 with nullptr [1].

At that time, there was again some discussion but I was suggested not to do it - rather keep *emulating* nullptr till all C++ toolchains support C++11 and nullptr.

If the opinion is now in favor of moving to nullptr, I would be more than happy about it.

[1] https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-dev/nullptr/chromium-dev/CrWPCeABSbY/Ds2tzRGtmnEJ

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Eric Seidel]

Happy to use whatever our compiler guru's tell us we can. nullptr is
more readable to me than 0.

The C++ 11 effort is being tracked here: http://crbug.com/360096. My
understanding is that much of that work overlaps with the question of
removing the emulation.

[Nico Weber]

The usual answer is, as far as I know:

* Not all compilers support C++11 yet (we're working on it). nullptr is a language feature.

* Once they do, there'll be a time where we have language features but not library features. std::nullptr_t, the type of nullptr, is a library feature

* Blink has its own nullptr emulation thing in third_party/WebKit/Source/wtf/NullPtr.h, inherited from WebKit, which can be used today

* But in the interest of being consistent with the rest of chromium, it shouldn't be used

Nico

[Peter Kasting]

On Tue, Jun 17, 2014 at 9:57 AM, Nico Weber <tha...@chromium.org> wrote:

* But in the interest of being consistent with the rest of chromium, it shouldn't be used

This is a bit of a strange argument, as the rest of Chromium uses NULL rather than 0 for null pointers.  (And, surprisingly, that rule actually seems to be followed pretty consistently.)

The only consistency argument for 0 would be consistency with existing Blink code.

PK 

[Julien Chaffraix]

> The usual answer is, as far as I know:
>
> * Not all compilers support C++11 yet (we're working on it). nullptr is a
> language feature.
> * Once they do, there'll be a time where we have language features but not
> library features. std::nullptr_t, the type of nullptr, is a library feature
> * Blink has its own nullptr emulation thing in
> third_party/WebKit/Source/wtf/NullPtr.h, inherited from WebKit, which can be
> used today

The reason I am asking is because contrary to Chromium, Blink already
has this emulation layer and people *are* using it. This email was
prompted by a review question and I was appalled to see that we still
advised people to use 0 when grep'ing for nullptr gives a lot of
results.

> * But in the interest of being consistent with the rest of chromium, it
> shouldn't be used

I think consistency between Blink's coding style and the code produced
is more important than that with another coding style. This is
especially true since Chromium is going to convert to using nullptr
once there is enough support.

Julien

[James Robinson]

Blink's emulated nullptr is great when it can be used (for instance to populate an empty PassOwnPtr), but the emulation isn't perfect and is restricted to be used only inside blink  (i.e. it can't be used across API boundaries).  I would say it's fine to use when it can be used, but we can't really encourage people to always use it when it doesn't always work.  Technically the emulation is in violation of the C++98 spec since it defines symbols in the std:: namespace, which is undefined behavior, but we've been lucky so far that it hasn't caused issues.

I don't really think there's a strong reason to prefer 0 or NULL in non-C++11 contexts, so consistency with existing code wins there.

Someday we'll be able to use the real std::nullptr at which point we should definitely encourage everyone to use it.

- James

[Mads Sig Ager]

I don't have strong opinions on general rules for the usage of 0 vs nullptr, but I can provide a bit of context on the increasing use of nullptr in Blink: the Oilpan transition types is what has recently made the use of nullptr much more common in Blink code. The reason is that we had to make RefPtr/OwnPtr/RawPtr/Member/Persistent consistently use either 0 or nullptr. Since OwnPtr already used nullptr we decided to use nullptr for all of them. That means that there are many places where you currently *have* to use nullptr. The exception is when you are dealing with actual bare T* pointers. The nullptr emulation should at this point allow you to use nullptr there as well but you don't have to and current code uses 0.

Cheers,    -- Mads