Comparison to null

  • Thread starter Thread starter juanph31
  • Start date Start date
J

juanph31

Hello there,

Why is it that I sometimes see this construct

//case 1
if ( null == myVariable)
{
//...etc
}


//case 2
if ( myVariable == null)
{
//...etc
}

Basically, what is the difference between the two?
 
To my knowledge, there is no difference.

I was taught to use the if(null == myVariable) method because a mistake
like using a = instead of == will be caught at compile time instead of
runtime.
 
It makes no difference, they are the same. The syntax is common for people
that have been programing in C/C++ for many years.

In C/C++ it is legal to write (single '=');

if(myVariable = null)
{
}

If you switch them around, it causes a compilation error because you cannot
assign a value to null.

if(null = myVariable)
{
}

Chris
 
Scott Klueppel via DotNetMonster.com said:
To my knowledge, there is no difference.

I was taught to use the if(null == myVariable) method because a mistake
like using a = instead of == will be caught at compile time instead of
runtime.
Click to expand...

Both of them will be caught at compile-time with C# though. There's no
reason to use this unnatural ordering in C#.
 
I swear I saw a code doing like that ( case 1 and case 2) in one method
and throwing difference exception for each. That's why I wanted to
know.

Juanph31
 
I swear I saw a code doing like that ( case 1 and case 2) in one method
and throwing difference exception for each. That's why I wanted to
know.

Juanph31
 
I don't think that

if(null == MyValue)
{
....
}

is a good habit to get into. I personally have not seen code like that in
any real world projects, but feel it would not be a proper coding standard
even if it makes no difference with comparison operators. And that would go
for any language IMHO.

Bob Calvanese
 
juanph31 said:
I swear I saw a code doing like that ( case 1 and case 2) in one method
and throwing difference exception for each. That's why I wanted to
know.
Click to expand...

Well, if you could show that code, I'd be interested to see it.
Admittedly there could be a difference if someone had overloaded the ==
operator and done it badly, but that's a bug in their operator
overloading rather than a feature of the language.
 
Hi All,

I think that a "key" is operator overloading.
Like a Jon post it before.

MyClass myVar;

if( null==myVar ) {
}
Doesn't have a chance to fire MyClass "==" operator function.

Marcin
 
Marcin Grz?bski said:
I think that a "key" is operator overloading.
Like a Jon post it before.

MyClass myVar;

if( null==myVar ) {
}
Doesn't have a chance to fire MyClass "==" operator function.
Click to expand...

Yes it does. Compile and run the following, ignoring the warnings:

using System;
using System.Data;

class Test
{
static void Main()
{
Test t = new Test();
Console.WriteLine (t==null);
Console.WriteLine (null==t);
}

public static bool operator == (Test t1, Test t2)
{
Console.WriteLine ("Operator== called");
Console.WriteLine ("t1={0}", t1);
Console.WriteLine ("t2={0}", t2);
return true;
}

public static bool operator!= (Test t1, Test t2)
{
return false;
}
}

The output is:
Operator== called
t1=Test
t2=
True
Operator== called
t1=
t2=Test
True

In other words, the overloaded operator is called both times.
 
Hi Jon,

Hmmm... it looks very strange for me.
But if that work then it seems that i was wrong.

:-(

I'm very curious how "operator==" will work with
class inheritance?

Marcin
 
Marcin Grz?bski said:
Hmmm... it looks very strange for me.
But if that work then it seems that i was wrong.

:-(

I'm very curious how "operator==" will work with
class inheritance?
Click to expand...

It doesn't, basically. At least, it's an overload rather than an
override. The situation is exactly the same as method overloads - if
you were given

void Foo (object x, object y)
and
void Foo (SomeClass x, SomeClass y)

and it were called with:

SomeClass y = new SomeClass();
Foo (null, y);

you'd expect the latter to be called, wouldn't you? That's exactly the
same with the == operator.
 
The reason someone may use this is so when they compile and put "=" instead
of "==" when doing comparisons, it will not compile and they will catch
their mistake.

But...

I feel that a programmer should not make these types of mistakes often
enough to get into bad coding habits such as this is (IMHO).
 
Bob Calvanese said:
The reason someone may use this is so when they compile and put "=" instead
of "==" when doing comparisons, it will not compile and they will catch
their mistake.

But...

I feel that a programmer should not make these types of mistakes often
enough to get into bad coding habits such as this is (IMHO).
Click to expand...

.... especially in C# when it won't compile if you put the "=" instead
anyway, unless you're comparing with a boolean.
 
Hi Jon,

I wrote two classes:

class OperatorTest {
public static bool operator==(OperatorTest ot1
, OperatorTest ot2) {
Console.WriteLine("OperatorTest.operator==({0}, {1})"
, ot1
, ot2);
return true;
}
};

and

class OperatorTestNext {
public static bool operator==(OperatorTestNext ot1
, OperatorTestNext ot2) {
Console.WriteLine("OperatorTestNext.operator==({0}, {1})"
, ot1
, ot2);
return true;
}
};

and i wrote the main code:

OperatorTest otA=new OperatorTest();
OperatorTest otB=new OperatorTestNext();
OperatorTestNext otC=new OperatorTestNext();

if( otA==null ) {
}
if( otB==null ) { // Here OperatorText's "==" has been called
}
if( otC==null ) {
}

And "otB" example works with .NET overload way.

Thanks!
Marcin
 
Marcin Grz?bski said:
I wrote two classes:
Click to expand...

<snip>

Assuming you meant OperatorTestNext to inherit from OperatorTest, that
just shows overloading working in exactly the normal way - overloads
are determined at compile time, not run-time. Change your operators to
static methods taking the same parameters and you'll see the same
behaviour.
 
Back
Top