Casting nullptr to bool

Question

In the pre-C++11 days it was considered better practice to write:

if (ptr == NULL)

Rather than:

if (!ptr)

This was for two reasons. It is more efficient because it didn't need to cast to bool. And there was no guarantee that the macro NULL would indeed evaluate to the boolean false. Is this still true in C++11? Is it preferable to write

if (ptr == nullptr)

Rather than

if (!ptr)

Or is the second fine now?

@Quentin Because !ptr is equivalent to ptr == nullptr, rather than ptr != nullptr — JulianSymes, Feb 16 '15 at 15:06
http://stackoverflow.com/questions/2597142/when-was-the-null-macro-not-0 — Benjy Kessler, Feb 16 '15 at 15:23
@knivil: In the world of hilarious pranks on other developers, in the same vein as `#define true rand() % 2 == 0 ? true:false` — AndyG, Feb 16 '15 at 15:34
"there was no guarantee that the macro `NULL` would indeed evaluate to the boolean `false`" - but it is guaranteed to evaluate to a null pointer constant, and `!ptr` is guaranteed to mean "not a null pointer". So both are (and always were) guaranteed to be equivalent, and there's no reason to expect either to be more efficient or regard either as "better" practice. — Mike Seymour, Feb 16 '15 at 15:40
Regardless of whether or not the statement !ptr is correct it is inefficient. As can be witnessed by the compiler warning: — Benjy Kessler, Feb 16 '15 at 15:52
@BenjyKessler People have answered the question you meant to ask, not the one you actually did. Just to be clear, you would _never_ write `if (ptr != nullptr)` instead of `if (!ptr)` because they have opposite meanings. — JulianSymes, Feb 16 '15 at 15:53
Discussed in http://stackoverflow.com/questions/1847860/why-is-there-a-performance-warning-on-cast-pointer-to-bool — Benjy Kessler, Feb 16 '15 at 15:53
This is the same compiler that claims that most of the C standard library and some of the C++ standard library is deprecated. That "performance warning" isn't worth the bytes it takes up. — T.C., Feb 16 '15 at 16:09

score 8 · Answer 1 · answered Feb 16 '15 at 15:02

It is more efficient because it didn't need to cast to bool.

I'd slap an ol' [citation-needed] at that. I doubt any modern compiler would make that count.

if (ptr) is perfectly fine and probably more semantically correct, if you're using that value to represent a canonical "lack of value".

I'd only expect to see if (ptr != nullptr) if someone was actually utilizing the "null" value for pointer arithmetic, but even then it's really sketchy.

That being said, a lot of times you can just get away with... not checking that at all. If the pointer's nullability is used to represent a nullable data field, use optional. If you are initializing it in case it's empty, use value_or idiom. If it's just a weak reference and the contract on value is outside, an assert will do.

http://stackoverflow.com/questions/1331292/c-rely-on-implicit-conversion-to-bool-in-conditions — Benjy Kessler, Feb 16 '15 at 15:03

score 5 · Answer 2 · answered Feb 16 '15 at 18:36

Re

” In the pre-C++11 days it was considered better practice to write:
if (ptr == NULL)
Rather than:
if (!ptr)

No, not by informed people.

” This was for two reasons. It is more efficient because it didn't need to cast to bool.

No, the two expressions are equivalent, one is not more efficient than the other. And a “cast” is a notation. It's meaningless to confuse that with execution efficiency.

” And there was no guarantee that the macro NULL would indeed evaluate to the boolean false.

There is indeed such a guarantee.

” Is this still true in C++11?

It's still all false in C++11, and in C++14, and will still be false in C++17.

AndyG · Answer 3 · 2015-02-16T15:09:40.420

4

Smart pointers like unique_ptr and shared_ptr have implicit conversions to bool that checks the internal pointer against nullptr, so the second is preferred in those cases, because the intent is well understood.

For raw pointers, I don't know if there's any actual guidance, but ptr != nullptr certainly explains the intent much more clearly (and what types are involved).

edited Feb 16 '15 at 15:09

answered Feb 16 '15 at 15:03

AndyG

39,700
8
109
143

score 3 · Answer 4 · answered Feb 16 '15 at 21:25

In C as many people here said it is indeed only a matter of style whether you implicitly cast to a bool or explicitly compare against NULL.

In C++11 however the story is different. nullptr provides type safety. Consider the following examples:

auto ptr = accessVal();
if (ptr == nullptr) {cout << "Pointer is null."};

vs.

auto ptr = accessVal();
if (!ptr) {cout << "Pointer is null."};

The first will only compile if ptr is a pointer. The second will compile if ptr can be implicitly casted to a bool.

To sum up the advantage of implicitly casting to bool is brevity. The advantage of comparing to nullptr is type safety. I think in most cases the benefit if type safety outweighs the benefit of brevity. Indeed this is the main reason for introducing the nullptr in C++11 in the first place.

score 2 · Answer 5 · answered Feb 16 '15 at 15:06

It's a matter of readability since the compiler is advanced to handle optimally both cases. One exception is if you create your own pointer class where !ptr must be evaluated by your code and suddenly the two syntaxes are not necessary equivalent. So I suggest when writing generic code to use if (ptr != nullptr) syntax.

Casting nullptr to bool

5 Answers5