10

Possible Duplicate:
What is the difference between these (bCondition == NULL) and (NULL==bCondition)?

I was going through a piece of C++ code and came across a code like

if (NULL != threadInfo)
{
  ...
  ...
}

I was just wondering is there any difference between using the expression 

if (threadInfo != NULL)
{
  ...
  ...
}

what is said above. While reading the first one reads " If NULL not equals to ThreadInfo" and the second one reads "If threadInfo not equals to NULL". To me the second one makes more sense.

Community
  • 1
  • 1
Anand
  • 316
  • 1
  • 14
  • 1
    When you tried this, what differences did you notice? – marto Jul 26 '11 at 12:44
  • 4
    You'll see alot of `if(Constant == variable)` in c/c++ because you'll get a compile error if you leave the second = off, trying to assign to a constant left hand expression. Maybe something similar? – asawyer Jul 26 '11 at 12:45
  • It does not make a difference, it's just a equation, you should see it more as just 2 values ( `if (true == true)` ) instead of variable and value. – Sander Jul 26 '11 at 12:45

11 Answers11

14

No, there is no difference. In case of == there might be some difference. The thing is that if you accidentally write = instead of == the compiler will give an error in the first case.

if (threadInfo = NULL) //always false. The compiler will give you a warning at best

if (NULL = threadInfo) //Compiler error

I personally hate that practice and think it's better to write code that can be read in a normal human language, not Yoda language.

Armen Tsirunyan
  • 130,161
  • 59
  • 324
  • 434
  • 6
    +1, definitely less readable, and for absolutely no gain whatsoever. If you often type `=` instead of `==` and also have *nothing* in place to warn you about it, then you might be having even bigger problems. – rid Jul 26 '11 at 12:48
  • 1
    The warning is useless, because template code generates a ton of false-positives. – Ben Voigt Jul 26 '11 at 12:55
7

It's for safety, so you don't accidentally write

threadInfo = NULL

instead of 

threadInfo == NULL

For the != there's no need to do this, but it's consistent.

Luchian Grigore
  • 253,575
  • 64
  • 457
  • 625
  • 5
    Turn. Compiler. Warnings. On. :| – GManNickG Jul 26 '11 at 13:04
  • 1
    I do have my compiler warnings on. However, I do like know the reason behind doing something rather than just doing it because others are doing it. I just stated the reason - which is a valid one - I didn't say you should not have warnings on... – Luchian Grigore Jul 26 '11 at 13:06
4

If threadInfo is of a type that overrides operator !=, and the owner of that class has not provided a symmetric free function that handles the case where the two arguments are swapped, there might be a difference (there might also be a need to fire that programmer).

Otherwise, it's a matter of taste. Probably it will be preferred by people who write if(42 == answer) instead of if(answer == 42) -- this protects you from mistyping an assignment operator instead of an equals check. But since modern compilers warn you when you do that, it's debatable whether this approach offers anything.

Jon
  • 428,835
  • 81
  • 738
  • 806
  • But the difference is that `NULL != threadInfo` won't compile, since int doesn't have a operator!= for the threadInfo type. I don't think there can be differences if threadInfo is a pointer type? – Douglas Leeder Jul 26 '11 at 12:55
  • @Douglas: There might be a free-function `operator !=(int, threadInfo_TYPE)` defined in the same namespace as `threadInfo_TYPE`, in which case it will be automatically brought into consideration due to Koenig Lookup. – Jon Jul 26 '11 at 13:03
2

There is no difference. The point of writing NULL != ... is that if you instead make a typo and write NULL = ... the code won't compile. If you had ... = NULL it could be a valid assignment and the error could go unnoticed (but most compilers detect this and warn you). Somebody once tried to insert a backdoor into the Linux kernel using this technique.

Also note that most persons don't code like that.

Quentin Pradet
  • 4,691
  • 2
  • 29
  • 41
2

There is no difference, EXCEPT that the first option cannot be mistyped as:

if (threadInfo = NULL)
{
    ...
    ...
}

And some people don't know how to use compiler switches to check this (and some compilers don't have them).

Peter K.
  • 8,028
  • 4
  • 48
  • 73
1

No difference, this is so called Yoda coding convention.

if (NULL != threadInfo)

is equivalent to 

if (threadInfo != NULL)

and to 

if (threadInfo)
ruslik
  • 14,714
  • 1
  • 39
  • 40
0

This is usually used as a convention, and has no distinct meaning by itself.

Because assignment occurs to lvals, and NULL is unassignable, this protects against the dreaded threadInfo = NULL when you meant threadInfo == NULL or threadInfo != NULL bug.

For more detail, see this wikipedia article section on left-hand comparisons

Nate
  • 12,499
  • 5
  • 45
  • 60
0

Both do the same thing. It is a style convention that was used to avoid typing mistakes as:

if (value=NULL) // assignment instead of == operator 
{ 
}
Vincent Mimoun-Prat
  • 28,208
  • 16
  • 81
  • 124
0

These are exact equivalents in terms of logic.

The second is more intutive, when one may see the first is seen as more safe as it doesn't allows writing (threadInfo = NULL) erroneously, leading to a bug.

Shlublu
  • 10,917
  • 4
  • 51
  • 70
0

Null is a reference in the memory contains nothing but that nothing have an address to access it.

By that you can make a comparisons behind null to check if a certain object have a value or nothing.

Mohammed Amr
  • 307
  • 5
  • 15
0

I don't see any difference. However, the practice of writing NULL == someVar would save you from writing NULL = someVar if you forget typing the second =.

Gowtham
  • 1,465
  • 1
  • 15
  • 26