0

As the title says. When checking if a node is nullptr, is there any difference between if(!node) and if(node == nullptr) or are they equivalent (given that node == NULL is not equivalent to node == nullptr).

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
akvn
  • 57
  • 1
  • 8
  • 2
    Except style and personal preference? Then no there's no difference. You could build a program which does both, then check the generated assembly to see if there's a difference (remember to always check an optimized builds). The compiler should treat `node == 0`, `node == NULL`, `node == nullptr` and `!node` equal (and keep in mind that the macro `NULL` is most likely expanded to `0`, so the two first are *exactly* same). – Some programmer dude Apr 14 '23 at 02:16
  • What makes you think `node == NULL` is not equivalent to `node == nullptr`? Since C++11, they are literally identical, with `NULL` defined via `#define NULL nullptr`. These four functions using `!x`, `x != 0`, `x != NULL` and `x != nullptr` produce identical assembly: https://godbolt.org/z/46cdEse5f – user229044 Apr 14 '23 at 02:27
  • Your inference that `node == NULL` is not equivalent to `node == nullptr` is incorrect. When `node` is a pointer and `NULL` a null pointer constant (such as the definition it has in standard headers), they are equivalent. Use of `nullptr` is more type-safe (e.g. using `nullptr` where an `int` is expected is a diagnosable error) but that doesn't mean comparisons using them are not equivalent. In any event, where `node` is a pointer, the expressions `!node`, `node == NULL`, and `node == nullptr` all give the same result (a `bool` that is `true` if `node` is a null pointer). – Peter Apr 14 '23 at 02:31
  • @user229044 I meant that `NULL` can be used in place of an integer as zero. Hence, they are not equivalent in this particular scenario. – akvn Apr 14 '23 at 02:33
  • 2
    `given that node == NULL is not equivalent to node == nullptr` is wrong though. They ARE equivalent. Also, `nullptr` can be converted to an integer via: `static_cast(nullptr)` and it would typically produce `0`. – Brandon Apr 14 '23 at 02:56
  • Refer to [how to ask](https://stackoverflow.com/help/how-to-ask) where the first step is to search and then research and you'll find plenty of dupes for this. – Jason Apr 14 '23 at 04:26

2 Answers2

2

So in terms of assembly produced. There is no difference. See this live example.

In terms of readability, it is an opinion, but the cppcoreguidelines prefer if (!node):

ES.87: Don’t add redundant == or != to conditions

Reason: Doing so avoids verbosity and eliminates some opportunities for mistakes. Helps make style consistent and conventional.

The example they give replicates yours very closely:

// These all mean "if p is not nullptr"
if (p) { ... }            // good
if (p != 0) { ... }       // redundant !=0, bad: don't use 0 for pointers
if (p != nullptr) { ... } // redundant !=nullptr, not recommended
Fantastic Mr Fox
  • 32,495
  • 27
  • 95
  • 175
  • 1
    I usually am very onboard with cpp core guidelines. In this case I actually prefer being explicit. – bolov Apr 14 '23 at 03:30
1

The generated code should be the same either way.

The primary advantage of nullptr is that it can only be compared to a pointer, so if (for example) you one variable named node and one named anode, and your IDE "helps" you by completing nod to anode, the result won't compile unless anode also happens to be a pointer.

By contrast, if (anode), if (!anode), if (anode == 0) and if (anode == NULL) will all compile for anode being quite a few different types (any pointer, integer, floating point, bool, non-class enumeration, and a fair number of others).

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111