dotNET Rant [modified]

[TheGreatAndPowerfulOz]

ok, an MSIL lawyer! perhaps, it got optimized away. In any case, the result is false.

Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/

[Rama Krishna Vavilala]

ahmed zahmed wrote:

== calls Equals

No. It calls Equals only when some class has overloaded the == operator (aka string). For objects == always means reference comparison. Also if it called Equals, you would not have had the problem in the first place. Because, one.Equals(two) will return true in your application. [Edit] Thanks for the one vote [/Edit]

[PIEBALDconsult]

Nooo... that's correct. Otherwise, what would you do with this:

int one = 0 ;
int two = 0 ;

bool same = (object) one == (object) two ;

Shouldn't this perform the same reference comparison of your code? (Man, you miss one closing quote... :-O )

modified on Thursday, May 6, 2010 7:38 PM

[TheGreatAndPowerfulOz]

eh? why are you showing me javascript?

Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/

[Lost User]

ahmed zahmed wrote:

perhaps, it got optimized away.

I very much doubt it. The C# compiler only seems to do trivial constant folding (without using commutativity etc) and some limited dead code elimination (after an unconditional return etc) The JIT compiler does the rest (which is not a lot, either) If it changes the result it is not an "optimization" but a bug. And, this was a Debug build, as can easily be seen. Here is the same code compiled in Release mode.

.locals init (
    \[0\] object x,
    \[1\] object y)
L\_0000: ldc.i4.0 
L\_0001: box int32
L\_0006: stloc.0 
L\_0007: ldc.i4.0 
L\_0008: box int32
L\_000d: stloc.1 
L\_000e: ldloc.0 
L\_000f: ldloc.1 
L\_0010: ceq 
L\_0012: call void \[mscorlib\]System.Console::WriteLine(bool)
L\_0017: ret

[TheGreatAndPowerfulOz]

Whatever, the point is, it didn't do as, at least, *I* expected. Perhaps its a compiler optimization that it's able to do from context. Try this:

bool compare(object a, object b)
{
return a == b;
}

bool result = compare(0, 0);

I'm not sure if the actual result or my expectation is correct. In any case, I wasted a lot of time on this because staring at the code it sure looked like it should "work."

Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/

[Lost User]

Hax edit: that was about what that post said when it was still breaking the forum.

modified on Friday, May 7, 2010 7:48 AM

[TheGreatAndPowerfulOz]

The one vote wasn't me. Look, whether I use == or .Equals should be semantically the same. so, leaving null values out of the picture, the result of a == b should be the same as calling a.Equals(b). if not, then something or other is fracked.

Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/

[Lost User]

This in Main:

L\_0000: ldc.i4.0 
L\_0001: box int32
L\_0006: ldc.i4.0 
L\_0007: box int32
L\_000c: call bool Test.Program::compare(object, object)
L\_0011: pop 
L\_0012: ret 

This in compare:

L\_0000: ldarg.0 
L\_0001: ldarg.1 
L\_0002: ceq    // still a reference comparison..
L\_0004: ret 

More importantly, I would like to point you to page 41 of 553 in ECMA-364 2nd edition where it says "Two expressions of type object are considered equal if both refer to the same object, or if both are null." The spec is usually right..

[Rama Krishna Vavilala]

ahmed zahmed wrote:

whether I use == or .Equals should be semantically the same.

But it is not. Consider this:

string s = "ahmed";
string s1 = "zahmed";

Console.WriteLine(s.Equals(s1.Substring(1)));
Console.WriteLine(s == (s1.Substring(1)));

Console.WriteLine((object)s == (s1.Substring(1)));

What do you think the output will be? It has to be: 1. true 2. true (the operator == in string is overloaded) 3. false (reference comparison)

[TheGreatAndPowerfulOz]

harold aptroot wrote:

The spec is usually right

ok, then it's a design flaw.

Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/

[Lost User]

Then you will also have to do battle with floats and doubles, NaN == NaN is false, but NaN.Equals(NaN) is true :)

[TheGreatAndPowerfulOz]

that's exactly my point. 3. should be true (in my opinion)

Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/

[TheGreatAndPowerfulOz]

harold aptroot wrote:

NaN == NaN is false

already knew this, by definition that is the case.

harold aptroot wrote:

NaN.Equals(NaN) is true

how queer. that I would assume to be a bug.

Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/

[Rama Krishna Vavilala]

Ok, but it ain't so.

[Lost User]

Is has to be like that, though. Otherwise either the "a.Equals(a) must be true" identity is violated (which would make some of the non-generic .NET 1.1 collections fail*), or the rules for IEEE floating point comparison are.. * you could put a NaN into an ArrayList and then use Contains, only to find that the NaN has "disappeared" but is still taking up a slot somewhere and you can clearly see it in the debugger.. :)

modified on Thursday, May 6, 2010 7:35 PM

[TheGreatAndPowerfulOz]

well, by definition comparing NaN to NaN results in truefalse. (sorry, brain fart). So, whether I use == or .Equals the result should be the same. I don't see why what I want would make "a.Equals(a) must be true" identity a violation, even in the case of NaN. NaN.Equals(NaN) being true violates IEEE.

Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/

[TheGreatAndPowerfulOz]

obviously! hence my RANT!

Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/

[Lost User]

My edit was too slow: You could put a NaN into an ArrayList and then use Contains, only to find that the NaN has "disappeared" but is still taking up a slot somewhere and you can clearly see it in the debugger.. :) edit: more generally, doing things like that break the Liskov substitution principle - that is Bad. edit2: It's almost 2am so I'm going to sleep for a bit.. I'll definitely check this thread out tomorrow morning though

modified on Thursday, May 6, 2010 7:51 PM

[PIEBALDconsult]

No, it isn't, it's correct.