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

- 37,467
- 22
- 115
- 187

- 34,529
- 29
- 100
- 137
-
The second style is often used in order that a compiler error pops up if the coder accidentally uses a single equals sign (assignment operator). I know of no other reason to do this. – Grimm The Opiner Jun 26 '13 at 14:36
-
and in C++11 you would of course use `nullptr` – TemplateRex Jun 26 '13 at 14:44
-
If only, sigh... ;-) – Grimm The Opiner Jun 26 '13 at 15:32
5 Answers
These are Yoda Conditions and in this case there is no reason to use them apart from choosing a specific coding style.
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

- 21,561
- 9
- 74
- 114
-
Surely Yoda would say `if(5 count ==)` ... ? ;-) Wouldn't compile though. – Grimm The Opiner Jun 26 '13 at 15:33
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

- 94,763
- 41
- 167
- 253
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).

- 126,704
- 14
- 140
- 227
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.

- 356,200
- 43
- 426
- 500
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.

- 1
- 1

- 24,090
- 7
- 47
- 71