0

What is difference betweeen var_ptr==NULL and NULL==var_ptr? Is there any behaviour changes in various arch?

Kiril Kirov
  • 37,467
  • 22
  • 115
  • 187
joe
  • 34,529
  • 29
  • 100
  • 137

5 Answers5

2

These are Yoda Conditions and in this case there is no reason to use them apart from choosing a specific coding style.

yoda condition

As written in the wiki article, it is considered an advantage that an unwanted assignment will be reported as error when an assignment operator = is used instead of equals == operator.

if (ptr = NULL) // valid code, may produce a warning on some compilers
if (NULL = ptr) // invalid, reported as error during compile time

Though in my opinion the readability of the latter is much worse.

There is a gain when a kind of Yoda condition is used (in Java or C#) like this:

"constant string".equals(yourVariableString)

Because there is no chance of getting NullPointerException

Dariusz
  • 21,561
  • 9
  • 74
  • 114
1

There is no difference. It's just a way to prevent unintended assignments. For example:

if (var = true); // I meant to compare, but this will still compile

as opposed to:

if (true = var); //  I meant to compare, but this WON'T compile
David G
  • 94,763
  • 41
  • 167
  • 253
1

Inside the compiler, you will still get an instruction that compares the pointer value with constant value of zero. This instruction, in most processors, only exist in a single form (although sometimes, there are multiple ways to achieve the same thing, such as AND R0, R0 is the same as CMP $0, R0 (or, in some archiectures, MOV var_ptr, R0 will set the flags so that the next instruction can be a "jump if not zero") - and depending on what processor architecture, it may be faster to do one than the another variant. But in the end, it still amounts to a single compariso with a constant zero. Even the most trivial compilers should be able to optimise either of these variants into the same thing whichever variant of "is this variable NULL" you choose to use. (You left out if (!var_ptr) in the list of choices - and of course, there are some more complex ways to achieve the same result, and I'm sure someone with that mindset can come up with soemthing complicated that the compiler makes a mess of).

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
0

Some people prefer the

NULL == var_ptr

option, as it protects against accident "assignment" typos, e.g.

if (NULL = var_ptr) { ... }

would raise a syntax error, as you're assigning to a constant. The other way around,

if (var_ptr = NULL) { ... } 

is syntactically correct, but almost certainly NOT what you'd intended.

Marc B
  • 356,200
  • 43
  • 426
  • 500
0

To check whether there is any difference I compiled a small snippet in VS 2012, Debug mode without optimization

int * p = NULL;
if (p == NULL) p = NULL;
if (NULL == p) p = NULL;

x86

if (p == NULL)  -(disassembly)->    cmp dword ptr [p],0
if (NULL == p)  -(disassembly)->    cmp dword ptr [p],0

x64

if (p == NULL)  -(disassembly)->    cmp qword ptr [p],0
if (NULL == p)  -(disassembly)->    cmp qword ptr [p],0

The compiler produces the same code, regardless of whether you have NULL or p first. Therefore it's just a matter of style and the question on why to have non-lvalues on the left side? has already been linked, as well as the wiki post refering to the Yoda-Condition directly which gives some hints why it is preferable not to have the lvalue on the left.

Community
  • 1
  • 1
Pixelchemist
  • 24,090
  • 7
  • 47
  • 71