dotNET Rant [modified]
-
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/ -
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?
Pete Appleton wrote:
void* one = 0; void* two = 0; BOOL same = (one == two); // false - the lvalues of one and two are different
wrong, same would have a value of true. one and two would be null pointers.
Pete Appleton wrote:
BOOL sameValue = (*one == *two); // true - the rvalues are the same
this would crash with a null pointer dereference error.
Pete Appleton wrote:
*one = 1; *two = 2; same = (one == two); // false - the lvalues are different
correct
Pete Appleton wrote:
sameValue = (*one == *two); // false - the rvalues are different now
this would crash with a illegal memory reference error
Pete Appleton wrote:
There's a reason why C# is called a C-based language... you may wish to brush up on your knowledge of pointers...
perhaps you should.
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/ -
Pete Appleton wrote:
void* one = 0; void* two = 0; BOOL same = (one == two); // false - the lvalues of one and two are different
wrong, same would have a value of true. one and two would be null pointers.
Pete Appleton wrote:
BOOL sameValue = (*one == *two); // true - the rvalues are the same
this would crash with a null pointer dereference error.
Pete Appleton wrote:
*one = 1; *two = 2; same = (one == two); // false - the lvalues are different
correct
Pete Appleton wrote:
sameValue = (*one == *two); // false - the rvalues are different now
this would crash with a illegal memory reference error
Pete Appleton wrote:
There's a reason why C# is called a C-based language... you may wish to brush up on your knowledge of pointers...
perhaps you should.
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/Do apologise - I missed the dereference void *one = &0; void *two = &0; Good thing I haven't used C for years :)
-- What's a signature?
-
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 think your example would be a corner case for floats and doubles if my way were to be adopted as I would still want to honor the IEEE meaning for NaN comparisons. However, I'm not a purist so much as a practical person. Anyway, this "argument" is moot, things are what they are, and I think we understand each other. And things certainly aren't going to change just cause *I* want them to. I was just having a temporary "brain fart". It just seems wrong that == and .Equals operate differently.
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/modified on Monday, May 10, 2010 12:50 PM
-
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
Well, it seems that it would given my remembered(and corrected/reminded) understanding. So 'same' would be false. (Haven't typed it into a compiler yet so I don't really 'know' -- lol). In any case, my rant was incorrectly focused. I was really venting about a larger issue and focused on this one small thing. Still, looking at it from a novice perspective (which I'm not -- even though it sure sounded like it yesterday --, but it helps sometimes to do that), it seems incongruous to have the result it does. Of course, once explained to said novice, it's understood. It's just programming after all, and each language/runtime has its 'quirks'. cheers.
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
That's an interesting oddity, to be sure. I don't see why the second case is not boxing. Isn't any literal integer a value type by definition? So then, if the two examples are different, then what is boxed in the first case? A reference to the iOne, iTwo variables? Or are their respective values boxed? And then what is the second case called, if not boxed? Consider the following code.
void func(out object one, out object two)
{
int iOne = 1;
one = iOne;two = 2;}
what is in 'one' and what is in 'two' after the return of this function? I submit they're both boxed. Of course, I admit I'm no expert and I'm fully ready to be instructed.
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/ -
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/What makes you think that a == b and a.Equals(b) should be the same? They are by definition different, and specifically used to check different things, both of which are necessary. Reference equals (the == operator, or the more explicit Object.ReferenceEquals method) checks to see if two variables (or pointers, since you are dealing with reference types) point to the same object in memory, e.g., do they have the same address. Using a.Equals(b) is the same as Object.Equals(a, b), and it compares the values of the two objects. This is very well defined behavior, and most programming languages discern the difference between reference and value comparison. Just because you have not understood the problem, or better yet, the solution to the problem, does not mean that it is a design flaw. To assert that it is a design flaw it to also assert that you have a complete understanding of the language and the specification, and clearly, you do not.
-
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/Ooh, a promising more short term and immediate lawyer prospect for me, until I get my law degree. And it'll help with my work. :)