dotNET Rant [modified]
-
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]
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/ -
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/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: retThis in compare:
L\_0000: ldarg.0 L\_0001: ldarg.1 L\_0002: ceq // still a reference comparison.. L\_0004: retMore 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..
-
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/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)
-
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/ -
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: retThis in compare:
L\_0000: ldarg.0 L\_0001: ldarg.1 L\_0002: ceq // still a reference comparison.. L\_0004: retMore 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..
harold aptroot wrote:
The spec is usually right
ok, then it's a design flaw.
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/ -
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)
that's exactly my point. 3. should be true (in my opinion)
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/ -
Then you will also have to do battle with
floats anddoubles, NaN == NaN is false, but NaN.Equals(NaN) is true :)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/ -
that's exactly my point. 3. should be true (in my opinion)
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/Ok, but it ain't so.
-
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/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
-
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
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/ -
Ok, but it ain't so.
obviously! hence my RANT!
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/ -
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/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
-
harold aptroot wrote:
The spec is usually right
ok, then it's a design flaw.
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/No, it isn't, it's correct.
-
ok, this is not a programming question. It's a rant! given,
object one = 0;
object two = 0;
bool same = one == two;what would you expect the value of
sameto be? WRONG! it's false! Whoever thought that was a valid result, is cracked!:mad::mad::mad::mad::mad: [edit] so, after going home and resting my brain a bit. it seems as though i'm the one that was cracked. thanks for the refresher course everyone. it is of course doing a reference comparison. which is correct. you all know how it is when you struggle with something and get too close to the trees to see the forest. anyway thanks to everyone for being your normally brutally honest selves. cheers. :-D [/edit]Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/modified on Friday, May 7, 2010 1:08 AM
In this context the
falseis about identity, not value: it returnsfalsebecause the the two instances are distinct (different object instances).Steve
-
In this context the
falseis about identity, not value: it returnsfalsebecause the the two instances are distinct (different object instances).Steve
understood, just not the expected result in the context I was doing the code. The example given was way simplified.
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/ -
No, it isn't, it's correct.
obviously, my statement was an opinion. but, i'll deal with reality rather than my wishfulness.
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/ -
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
harold aptroot wrote:
doing things like that
not sure what you mean. The arrayList.Contains "failing" or my argument that == and Equals should be the same?
harold aptroot wrote:
iskov substitution principle
Don't know what that is I'll have to look it up.
harold aptroot wrote:
almost 2am
go get some sleep. and dream beautiful dreams.
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/ -
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)
To complicate matters: you do know some of those strings will be interned, and some won't. Now this thread is more technical than any of today's threads in the C# forum. It is time you realize this still is The Lounge. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
Prolific encyclopedia fixture proof-reader browser patron addict?
We all depend on the beast below.
-
ok, this is not a programming question. It's a rant! given,
object one = 0;
object two = 0;
bool same = one == two;what would you expect the value of
sameto be? WRONG! it's false! Whoever thought that was a valid result, is cracked!:mad::mad::mad::mad::mad: [edit] so, after going home and resting my brain a bit. it seems as though i'm the one that was cracked. thanks for the refresher course everyone. it is of course doing a reference comparison. which is correct. you all know how it is when you struggle with something and get too close to the trees to see the forest. anyway thanks to everyone for being your normally brutally honest selves. cheers. :-D [/edit]Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/modified on Friday, May 7, 2010 1:08 AM
You have to remember, they were copying Java. You need to use object.Equals for that situation. It's not intuitive, but it's the choice the designers made.
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
-
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
Ian's next book could be titled "The Mystery of the Vanishing NaN" then? :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
Prolific encyclopedia fixture proof-reader browser patron addict?
We all depend on the beast below.