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.WriteLi ne("a==b " + (a==b)); // prints False

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

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

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

Console.WriteLi ne("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.Referenc eEquals(a, null);
bool bNull = object.Refernec eEquals(b, null);

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

if (!object.Refere nceEquals(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.
--
"Aamir Mahmood" <a@b.c> wrote in message
news:%2******** **********@TK2M SFTNGP15.phx.gb l...

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.WriteLi ne("a==b " + (a==b)); // prints False

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

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

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

Console.WriteLi ne("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.Referenc eEquals(a, null);
bool bNull = object.Refernec eEquals(b, null);

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

if (!object.Refere nceEquals(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.

[Jon Skeet [C# MVP]]

Aamir Mahmood <a@b.c> wrote:

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.Referenc eEquals(a, null);
bool bNull = object.Refernec eEquals(b, null);

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

if (!object.Refere nceEquals(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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[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]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Aamir Mahmood <a@b.c> wrote:

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.Referenc eEquals(a, null);
bool bNull = object.Refernec eEquals(b, null);

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

if (!object.Refere nceEquals(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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Aamir Mahmood <a@b.c> wrote:

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

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too