dotNET Rant [modified]
-
Of course it's false! You just compared the references of two OBJECTS, not two values. It seems that you're the one who's "cracked".
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...well, you know how it is, i'm sure when you're doing something all day long and your brain gets fried. yep, i was the one cracked, for sure.
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/ -
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
lol, yep you are right. that's me, the cracked one.
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/ -
ahmed zahmed wrote:
One would expect that the comparators of the boxed values would be used. so, the result would be true, as I initially expected.
Why do you think these are being boxed? You are clearly assigning values to an object instance. This doesn't result in any boxing operations.
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
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/ -
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
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......
-
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
-
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 remember me
Javanewbies using the==operator with strings... :rolleyes:If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
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?