dotNET Rant [modified]
-
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
The deeper question is why does auto boxing not return the same object.
-
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
void* one = 0; void* two = 0; BOOL same = (one == two); // false - the lvalues of one and two are different BOOL sameValue = (*one == *two); // true - the rvalues are the same *one = 1; *two = 2; same = (one == two); // false - the lvalues are different sameValue = (*one == *two); // false - the rvalues are different now There's a reason why C# is called a C-based language... you may wish to brush up on your knowledge of pointers...
-- What's a signature?
-
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 -
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
-
The deeper question is why does auto boxing not return the same object.
Because keeping all 2^32 possible integers around until they are (maybe) reused would waste up to 48 GB of RAM (or 96 GB on 64-bit systems, as the overhead of objects is higher there). And I don't really want the Java behavior where all integers between -128 and 127 return the same object, but all other integers don't.
-
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/Ok well if you would make == and Equals the same, either you would have to violate the "NaN == NaN is false" rule by saying that both == and Equals return true for two NaN's (potentially messing up peoples floating point maths, causing extra conversion problems between C# and other languages and reducing performance for floating point equality comparisons), or you would cause mayhem by allowing a case where a.Equals(a) is false (namely in the case that a is NaN) which causes unexpected results such as being unable to remove a NaN from a collection except by index (but you can't really get that index, either, except with some custom code that checks whether any element is unequal to itself) That "mayhem" can be "solved" by not using Equals like that. But then Equals has become essentially useless, since you can never count on its result having the same meaning - who knows maybe someone will throw in a NaN (maybe even on accident) and break your code.
-
I'm new to c#, can anyone tell me how i can generate such a list file or at least how to see that code, tried a lot never succeeded to obtain it.
-
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/I agree with Ahmad. == and Equals are ambiguous as to what they are doing. In my opinion == and Equals() should always be a value comparison, as that is the natural expectation of non programmers. "ref ==" or some other syntax should do a reference comparison. I think its poor language design in C#. The == operator has effectively been over loaded with two different semantic meanings, it was a silly idea.
-
Because keeping all 2^32 possible integers around until they are (maybe) reused would waste up to 48 GB of RAM (or 96 GB on 64-bit systems, as the overhead of objects is higher there). And I don't really want the Java behavior where all integers between -128 and 127 return the same object, but all other integers don't.
Daniel Grunwald wrote:
And I don't really want the Java behavior where all integers between -128 and 127 return the same object, but all other integers don't.
Ooh, that's nasty. I'd be curious to know why == defaults to reference comparison though - after all, Equals is available in System.Object. I can think of edge cases where the LHS is null and therefore the (virtual) call can't be made, but other than that...
Regards Senthil _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
-
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
I understand where your coming from. Its a design flaw in the C# language, Equals() and == are ambiguous. They are overloaded to do two semantically different operations but they use the same syntax. Its a really stupid idea, that can only lead to logic mistakes. One of the good ideas in C# was forcing the contents of If statements to evaluate to a Boolean. This was to avoid many errors coded in the past in C and C++. But then the designers of C# didn't see the fundamental problem with overloading the == operator. At least they didn't make the assignment operator (=) use the same syntax. They should have made reference equals use something else like "ref ==" Why else do they have the ref parameter for passing parameters to functions, to avoid ambiguity. Someone one day will count errors generated in C# in a big project and I would not be surprised if reference == will be a percent or two of all bugs. And it never had to happen, pity.
-
Daniel Grunwald wrote:
And I don't really want the Java behavior where all integers between -128 and 127 return the same object, but all other integers don't.
Ooh, that's nasty. I'd be curious to know why == defaults to reference comparison though - after all, Equals is available in System.Object. I can think of edge cases where the LHS is null and therefore the (virtual) call can't be made, but other than that...
Regards Senthil _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
I dont think there is a reason, just a coin toss. Because everything inherits from object it might be easier to compare the pointer values. But they could just as easily have done a ToString() on each object and compared values. Maybe its to deal with null references, where ToString() would not work? But then they could always have had some pre defined rule as when two null references are compared they are equal, like if both null then they are equal otherwise false
-
ahmed zahmed wrote:
Whoever thought that was a valid result, is cracked
Well duh, it's supposed to be different, you're one who's cracked! Why don't you read up on value vs. reference comparisons. Marc
-
void* one = 0; void* two = 0; BOOL same = (one == two); // false - the lvalues of one and two are different BOOL sameValue = (*one == *two); // true - the rvalues are the same *one = 1; *two = 2; same = (one == two); // false - the lvalues are different sameValue = (*one == *two); // false - the rvalues are different now There's a reason why C# is called a C-based language... you may wish to brush up on your knowledge of pointers...
-- What's a signature?
-
I understand where your coming from. Its a design flaw in the C# language, Equals() and == are ambiguous. They are overloaded to do two semantically different operations but they use the same syntax. Its a really stupid idea, that can only lead to logic mistakes. One of the good ideas in C# was forcing the contents of If statements to evaluate to a Boolean. This was to avoid many errors coded in the past in C and C++. But then the designers of C# didn't see the fundamental problem with overloading the == operator. At least they didn't make the assignment operator (=) use the same syntax. They should have made reference equals use something else like "ref ==" Why else do they have the ref parameter for passing parameters to functions, to avoid ambiguity. Someone one day will count errors generated in C# in a big project and I would not be surprised if reference == will be a percent or two of all bugs. And it never had to happen, pity.
Why else do they have the ref parameter for passing parameters to functions, to avoid ambiguity. No - it's so that you can do this: void func(void *ptr) { ptr = NULL; } // ... func(&ptr); The ref keyword is the equivalent of & ; it is NOT syntactic sugar.
-- What's a signature?
-
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
This is because dotNET is Microsoft's version of Java, and that is how Java would do it. My guess is that you are coming from a C++ background where you expect it to call operator==(). The main difference between Java and the first dotNET was that Java lowercased the first letter of methods, while dotNET uppercased the first letter. dotNET has evolved at a much faster (almost unstable) pace since then. Disclosure: I am a Java programmer that is glad that MS created dotNET. Java would probably still not have enums if MS hadn't ditched Java and started competing directly against it.
-
Because keeping all 2^32 possible integers around until they are (maybe) reused would waste up to 48 GB of RAM (or 96 GB on 64-bit systems, as the overhead of objects is higher there). And I don't really want the Java behavior where all integers between -128 and 127 return the same object, but all other integers don't.
Daniel Grunwald wrote:
where all integers between -128 and 127 return the same object, but all other integers don't.
I forgot about that. I was once stuck with a subtle bug due to that behavior.
-
ok, perhaps I'm misunderstanding something, but aren't value types boxed when assigned to an object? or passed as a parameter to a function whose parameter type is object?
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/If you had value types to start with, you are correct. Here is the difference...
int iOne = 1;
int iTwo = 2;object one = iOne;
object two = iTwo;In this case, you have created two value types (
iOneandiTwo, which you then assign to object variables. At the point of the assignment, the runtime is boxing the value types to reference types. However, in your case you haveobject one = 1;
object two = 2;Which is not the same. Here you are assigning the literal values to the object variables, which don't create any value types.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
-
ahmed zahmed wrote:
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.
When was the last time you took a vacation? This happens to me when I've not taken a vacation for too long......
Abhinav S wrote:
took a vacation
more than a year
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/ -
Ravi Santlani wrote:
stil in school
lol. nope. just working too long.
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/ -
Why else do they have the ref parameter for passing parameters to functions, to avoid ambiguity. No - it's so that you can do this: void func(void *ptr) { ptr = NULL; } // ... func(&ptr); The ref keyword is the equivalent of & ; it is NOT syntactic sugar.
-- What's a signature?
I dont think he was complaining about the 'ref' keyword, but rather the way == is overloaded on object to mean "compare" pointers. But, then when all you have is an 'object' what else can you do? Still it seems that the runtime knows that it's a boxed value-type and could do something 'smarter'. But I don't know the full implications of doing something like that, at least not now. Who knows what would break.
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/