Re: Operator overloading.
Re: Operator overloading.
Ok, so it was just a hash key. But what about the warnings. It is just because the users of my class will expect them to be overloaded, or should I take them serious?'
- ØØ -
Re: Operator overloading.
Quote:
Originally Posted by NoteMe
Ok, so it was just a hash key. But what about the warnings. It is just because the users of my class will expect them to be overloaded, or should I take them serious?'
- ØØ -
I should probably look this up rather than depend on my memory, but if memory serves, ignoring the overrides warning may not cause your code to blow up, but it also may cause the resources that are consumed by your code not to be released once the code has finished running. I tend to never ignore warnings, especially if I'm not completely sure what they mean.
Re: Operator overloading.
Yeah, that is why I asked. But I hate to add more stuff then nessesary to small tight classes. Like the has varning will make have an extra value in the class, and aslo extra calculation in the constructor. And that is not what I want for a small class that you can have hundreds of or maybe thousends of instasiated on the same time.
- ØØ -
Re: Operator overloading.
Surely if you overload == but not .Equals then using the two will give you different results for what should be considered the same expression. The two should be able to be used interchangeably so surely you must have matching implementations for each.
Re: Operator overloading.
Yes, its like when you are implementing IComparable. Your class neds to return 1 if A > B, this also means you MUST return -1 if A < B, nd 0 if they are the same. You can't only do half the checking.
Re: Operator overloading.
Ok, I get the point with Equals and ==. Even if I just think it is stupid. But ok, so what they actualy want me to do is to overload ==, and then over load Equal and make that function call the == overloading, or the other way around. And then if I want a function that compares the objects rather then the value, then I have to make a separate function for that, in stead of keeping the Equals for comparing objects.
But then the GetHashCode function is still a mysteri for me. Because it still works at it should. A test I just ran:
Code:
Vector3 v8 = new Vector3(1.0f, 1.0f, 1.0f);
Vector3 v9 = new Vector3(1.0f, 1.0f, 1.0f);
Vector3 v10 = v9;
Console.WriteLine("v8: " + v8.GetHashCode());
Console.WriteLine("v9: " + v9.GetHashCode());
Console.WriteLine("v10: " + v10.GetHashCode());
Outputs this:
Quote:
v8: -1404432640
v9: 45009472
v10: 45009472
So since it is basicaly a function for C# to check what object you are working on, rather for a human to check it, I can't see the reason why I have to override that one too. Plain stupid if you ask me.
As an other note. After I went home from work yesterday, I read up on operator overloading in my book. And the authour David Bishop compiles a DLL with a class for complex numbers. And he is overriding == and !=, but not Equal() or GetHashCode(). And when he compiles it, he says that you should not care about the two warnings. They doesn't matter in that case. So I guess that it is only for human readability, and that a human will expect Equals to call == and nothing more then that.
- ØØ -