Programming Test
I stumbled across Part 6 of a Programming Job Interview Challenge on the Dev102 blog and thought, “hey, I know this!” I couldn’t help responding.
So the question was, given this bit of code, what will the output be?
1: ArrayList a = new ArrayList();
2: ArrayList b = new ArrayList();
3:
4: a.Add(1);
5: b.Add(1);
6: a.Add(2);
7: b.Add(2.0);
8:
9: Console.WriteLine((a[0] == b[0]));
10: Console.WriteLine((a[1] == b[1]));
Ok, so I’ll break the post here in case you want to work it out for yourself, but you should really go to the original post - not least because there are five other challenges there.
Anyway, the short answer is you’d get two “false”s. The reason? It’s all to do with the way the information is stored, and how the equality operator works.
Usually, when you’re writing code in C#, you don’t have to think too much about how pieces of data are stored in memory. This is not one of those times. Because the primitive numbers are stored in an ArrayList, they are boxed into memory locations. If the code simply said “1 == 1″ rather than “a[0] == b[0]”, then you’d get a True, but because you’re comparing one memory location with another, they’re never going to be equal.
Now if you were to use the .Equals function, then you’d get a true result, at least for zeroth items of the ArrayLists (but not for the next one - 2 doesn’t equal 2.0).
So, let that be the lesson - if your primitives are wrapped (or boxed), then use the Equals method rather than the equals operator (==).
Duh… and the lesson is - used typed containers unless you REALLY have a good reason. C# and its dumb operators which aren’t virtual and can’t be overridden and the less than obvious use of Equals() as a solution….
Fair point - I can’t really think of an occasion where you don’t know what type of object is going in a list. Even if it needs to be reusable, just use generics. Actually, since .Net 2.0, I don’t think I’ve used ArrayList - the List generic does the same job and provides type safety.
That aside, use of the Equals function makes sense as long as you know what it means. You get the same behaviour with C++.
Unless you’ve overridden the behaviour for a class, Equals() gives you value equality and == gives you reference equality. For unboxed primitives, == will give the same answer as Equals.
Also, as a side note, you can actually override operators in C#: http://msdn.microsoft.com/en-us/library/ms173147(VS.80).aspx.
Can you override the == operator of the Object class?
You can’t change the behaviour of the == operator in the Object class I don’t think. You might be able to with extension methods in .Net 3.0, but I doubt it - haven’t tried it.
I meant that you can override the == operator (write your own definition) in any class you create and it will be called rather than the default Object behaviour.
Also, probably shouldn’t have said C++. I’m way too rusty on it and it looks like I’m a bit off with that suggestion (read: wrong). Java might have been more appropriate - or any language where everything is considered an object.
My intention was to suggest that in language similar to C#, the == operator will return false for two separate non-primitives regardless of their actual value.
[…] Brady wrote a beautiful answer in his blog as did Ricky in his blog Crazy Pointer and Siddharth in his blog Some […]