Boxing causing problem during comparisons

[Aamir Mahmood]

Hi

I am on framework version 1.1 (SP1). Consider the following code.

public static void Main() {

int i=1;

int j=1;

object a=1;

object b=1;

object c=i;

object d=j;

object e=i;

object f=i;

object g=b;

object h=b;

Console.WriteLine("a==b " + (a==b)); // prints False

Console.WriteLine("c==d " + (c==d)); // prints False

Console.WriteLine("i==j " + (i==j)); // prints True

Console.WriteLine("e==f " + (e==f)); // prints False

Console.WriteLine("g==h " + (g==h)); // prints True

}

-----

Initially I got confused why these output is False for any of the above
comparisons. But I found that this is because of boxing. I don't want to
say that boxing is wrong, but what I want to say that this feature is
causing problems for me because I cannot bring the actual value out of box
in my base class before the comparison. I have an object type in my base
class and child classes can assign any value type in that.

What I have concluded that MS has wrongly implemented the == operator for
object class. It should have been something like this

------
bool aNull = object.ReferenceEquals(a, null);
bool bNull = object.ReferneceEquals(b, null);

if (aNull && bNull) return true;
if (aNull || bNull) return false;

if (!object.ReferenceEquals(a, b)) {
return a.Equals(b);
}
return true;
------

If MS had implemented the == operator for object like the fragment above,
then there would have been no harm. Since this is not the fact, therefore,
we are facing unwanted boxing problems during comparisons.


Is there any workaround for this?


-
Aamir.

 

[Nick Malik [Microsoft]]

You coded a routine for the equals operation that you'd rather use... why
not use it instead of the == operator?
Or just a.Equals(b)?

The behavior you observed is expected and well documented when comparing
object references.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.

 

[Jon Skeet [C# MVP]]

What I have concluded that MS has wrongly implemented the == operator for
object class. It should have been something like this

No, you just wrongly interpreted it, IMO.

------
bool aNull = object.ReferenceEquals(a, null);
bool bNull = object.ReferneceEquals(b, null);

if (aNull && bNull) return true;
if (aNull || bNull) return false;

if (!object.ReferenceEquals(a, b)) {
return a.Equals(b);
}
return true;
------

If MS had implemented the == operator for object like the fragment above,
then there would have been no harm. Since this is not the fact, therefore,
we are facing unwanted boxing problems during comparisons.

Is there any workaround for this?

If you effectively want Equals to be called, just call Equals yourself.

 

[Aamir Mahmood]

If you effectively want Equals to be called, just call Equals yourself.
But Equals cannot be called on a null object. Why can't it be a default
implementation in object class? As I said it has no harm. and writing a
null safe code before calling Equals involves 5-6 extra lines just for
comparison of boxed variables

 

[Jon Skeet [C# MVP]]

But Equals cannot be called on a null object.

So call the static object.Equals (x, y) instead.

Why can't it be a default implementation in object class?

Direct reference comparisons are very cheap, so using them where
possible is a win.

As I said it has no harm. and writing a
null safe code before calling Equals involves 5-6 extra lines just for
comparison of boxed variables

No it doesn't - just use object.Equals if you don't know whether either
of them are non-null. If you know that one is non-null (x, say), just
call x.Equals(y) and you'll get false back if y is null.