Trick for young players.
-
LOL - I am genuinely crying (with a little laughter and a lot of WTF!)
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
Just pulling your leg a little bit. Shorthand for
ReferenceEqualsin VB.Net isIS.=is the shorthand forEquals. So the VB code wasn't the same as your C# code. :) I'v seen this error a few times in code that's been converted between VB and C#. C#==is not the same as VB=, but oh so easy to miss if you only know one of the languages. Should add that this is a standard error in all automatic converters I've tried.People say nothing is impossible, but I do nothing every day.
-
Look at the prog below - a collection has one(object)bool in it. And I want to find out if one of them exists in the collection. Using collection.Contains() would seem like a good idea. But isn't!
class Program
{
static void Main(string[] args)
{
object arg1 = true;
object arg2 = true;List<object> collection = new List<object>() { arg1 }; bool first = (collection.Contains(arg1)); bool second = (collection.Contains(arg2)); Console.WriteLine(string.Format("{0} {1}", first, second)); first = false; second = false; for (int i = 0; i < collection.Count; i++) { if (collection\[i\] == arg1) { first = true; } if (collection\[i\] == arg2) { second = true; } } Console.WriteLine(string.Format("{0} {1}", first, second)); Console.ReadKey(); } }MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
I used this article for reference: link
object arg1 = true;
object arg2 = true;
List<object> collection = new List<object>() { arg1 };The keyword object doesnt make 'arg1' or 'arg2' a reference type, they are both value types. And as the article clearly states "If the current instance is a value type, the Equals(Object) method tests for value equality. Value equality means the following: 1.The two objects are of the same type. 2.The values of the public and private fields of the two objects are equal." when checking
bool first = (collection.Contains(arg1)); bool second = (collection.Contains(arg2));as both the conditions are satisfied obviously 'Contains' will return true. As i understand this is exactly the same as doing
int a = 1; int b = 1; List intcollection = new List() {a }; bool first = (intcollection.Contains(a)); bool second = (intcollection.Contains(b)); Console.WriteLine(string.Format("{0} {1}", first, second));in which case we all agree that 'True True' is the output. I think the confusion occurs because of the tendency to assume object arg1 and object arg2 as reference types. I understand this can cause confusion and bigger underlying problems in a framework scenario but the only reason(AFAIK) causing this is whoever coded it dint realize this beforehand. but i appreciate this post as I know I would never have come across such a ascenario in years.Please feel free to correct me if I am wrong as I am one of the young players only :-).
-
Just pulling your leg a little bit. Shorthand for
ReferenceEqualsin VB.Net isIS.=is the shorthand forEquals. So the VB code wasn't the same as your C# code. :) I'v seen this error a few times in code that's been converted between VB and C#. C#==is not the same as VB=, but oh so easy to miss if you only know one of the languages. Should add that this is a standard error in all automatic converters I've tried.People say nothing is impossible, but I do nothing every day.
And then people complain about the confusing use of pointers and pointees in C/C++ ...
-
And then people complain about the confusing use of pointers and pointees in C/C++ ...
Pointers and Pointees have a point, but in 95% of the cases the compiler would do a better job in handling it for you, and you can concentrate on the programming instead. Just my 2c.
People say nothing is impossible, but I do nothing every day.
-
I used this article for reference: link
object arg1 = true;
object arg2 = true;
List<object> collection = new List<object>() { arg1 };The keyword object doesnt make 'arg1' or 'arg2' a reference type, they are both value types. And as the article clearly states "If the current instance is a value type, the Equals(Object) method tests for value equality. Value equality means the following: 1.The two objects are of the same type. 2.The values of the public and private fields of the two objects are equal." when checking
bool first = (collection.Contains(arg1)); bool second = (collection.Contains(arg2));as both the conditions are satisfied obviously 'Contains' will return true. As i understand this is exactly the same as doing
int a = 1; int b = 1; List intcollection = new List() {a }; bool first = (intcollection.Contains(a)); bool second = (intcollection.Contains(b)); Console.WriteLine(string.Format("{0} {1}", first, second));in which case we all agree that 'True True' is the output. I think the confusion occurs because of the tendency to assume object arg1 and object arg2 as reference types. I understand this can cause confusion and bigger underlying problems in a framework scenario but the only reason(AFAIK) causing this is whoever coded it dint realize this beforehand. but i appreciate this post as I know I would never have come across such a ascenario in years.Please feel free to correct me if I am wrong as I am one of the young players only :-).
TheCoolCoder wrote:
whoever coded it dint realize this beforehand.
in fact, when the framework was written, I think there were only a very limited number of objects that were intended to be passed - and all of these would have been reference objects. So, not necessarily that he didn't realise it, but more that he didn't consider anyone might try to pass a bunch of booleans!
TheCoolCoder wrote:
the tendency to assume object arg1 and object arg2 as reference types.
Spot on! Looked at in isolation, that is exactly what most people assume (myself included!). This would be a great example of where TDD would possibly have been useful - as in setting up tests with a variety of parameter types, this issue may have been spotted before going into production!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
Pointers and Pointees have a point, but in 95% of the cases the compiler would do a better job in handling it for you, and you can concentrate on the programming instead. Just my 2c.
People say nothing is impossible, but I do nothing every day.
I didn't intend to turn this into a C++ vs C# discussion, just point out that this specific case is just as confusing* as pointer use, which happens to be one of the stronger arguments against using C/C++. I'm not saying this is a common problem in C#, just gloating over the realization that you cannot completely avoid the heritage. ;P
-
I didn't intend to turn this into a C++ vs C# discussion, just point out that this specific case is just as confusing* as pointer use, which happens to be one of the stronger arguments against using C/C++. I'm not saying this is a common problem in C#, just gloating over the realization that you cannot completely avoid the heritage. ;P
I we would make a list of confusing parts of programming languages, any language, we would run out of harddisk space pretty soon. :-)
People say nothing is impossible, but I do nothing every day.
-
Look at the prog below - a collection has one(object)bool in it. And I want to find out if one of them exists in the collection. Using collection.Contains() would seem like a good idea. But isn't!
class Program
{
static void Main(string[] args)
{
object arg1 = true;
object arg2 = true;List<object> collection = new List<object>() { arg1 }; bool first = (collection.Contains(arg1)); bool second = (collection.Contains(arg2)); Console.WriteLine(string.Format("{0} {1}", first, second)); first = false; second = false; for (int i = 0; i < collection.Count; i++) { if (collection\[i\] == arg1) { first = true; } if (collection\[i\] == arg2) { second = true; } } Console.WriteLine(string.Format("{0} {1}", first, second)); Console.ReadKey(); } }MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
2 questions: 1. what is the problem, nothing really surprising in your program behaviors... (except, maybe newbie might be surprised by "((object)"A") != "A"") 2. your program doesn't seem to match your 1 line English sentence above?!?
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
2 questions: 1. what is the problem, nothing really surprising in your program behaviors... (except, maybe newbie might be surprised by "((object)"A") != "A"") 2. your program doesn't seem to match your 1 line English sentence above?!?
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
2 answers 1. The problem is that it is easy to be misled about what is happening in this sort of circumstance; Bearing in mind that, in the real world, the 'contains' code would be in a method that simply has a collection of objects as its parameter (so it's not obvious what values may be in those objects). If you are just saying that you would never be fooled by something like 'contains' finding some objects and not others, then I bow to your superior intellect. Oh, and the newbies being surprised thing is just off topic. I am certain that many a newbie (and quite a few oldies)_ would be fooled by the 'contains' issue with a mixture of objects, some of which are value and some reference, ESPECIALLY as the issue (in the case identified in some of my other responses) rears its head only when the values of two arguments happens to be equal - which leads to an irregular failure of a part of the framework. 2. Are you referring to 'a trick for young players'? If so, maybe this is an Aussie phrase. It means 'something to beware of for the inexperienced'
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')