[.net] Why can't I say if(struct1 == struct2) in C#?
Author
Aren't structs value types? Why isn't
if(struct1 == struct2)...
legal if they're of the same struct type?
You can say if(struct1 == struct2). THey are both value types so its legal but u cant say class1 == class2.
You have to override the == operator, and if you're going to do that, it'd make sense to override the Equals() function as well.
Quote:Original post by skittleoIn C# structs and classes are different. structs are allocated on the stack, whereas classes are allocated on the heap. Here's a more detailed description of the differences.
In C++ at least, structs and classes are basically the same thing, except that structs' members are by default public whereas classes' members are by default private. I would expect the same to be true in C#. You can always overload the == operator.
Author
But overriding .Equals is just syntactic sugar, it's not any faster than calling .Equals, and all I care about is performance in this particular app. I don't want the overhead of a .Equals method call.
Override the Equals method to compare your structs however you want, and then define a == operator which calls the Equals method. The JIT will almost certainly inline the == operator method, and if your Equals method is simple enough, probably that too.
Quote:Original post by NexusOne
But overriding .Equals is just syntactic sugar, it's not any faster than calling .Equals, and all I care about is performance in this particular app. I don't want the overhead of a .Equals method call.
If you were going to brand anything as "syntactic sugar", I would probably aim that comment at operator overloads, rather than the overriding of a virtual method, but hey...
Quote:Original post by Holy Fuzz
Override the Equals method to compare your structs however you want, and then define a == operator which calls the Equals method. The JIT will almost certainly inline the == operator method, and if your Equals method is simple enough, probably that too.
Actually, wouldn't it be better to implement this the other way around (i.e. have the member comparison in the == operator, and call this inside Equals), as a call to Equals would involve boxing/unboxing, whereas the body of the == operator method would have both objects typed as value-types?
Quote:Actually, wouldn't it be better to implement this the other way around (i.e. have the member comparison in the == operator, and call this inside Equals), as a call to Equals would involve boxing/unboxing, whereas the body of the == operator method would have both objects typed as value-types?
This is true. What I like to do is provide a custom, overloaded MyType.Equals(MyType obj) method, which is called by both the overriden Equals(object obj) method and the == operator. That way, there aren't any unboxing issues, and my personal preference is to not put any "meat" inside of operator methods, but instead to merely provide them as syntactic shortcuts to the methods that do the real work.
Quote:Original post by Holy Fuzz
This is true. What I like to do is provide a custom, overloaded MyType.Equals(MyType obj) method, which is called by both the overriden Equals(object obj) method and the == operator. That way, there aren't any unboxing issues, and my personal preference is to not put any "meat" inside of operator methods, but instead to merely provide them as syntactic shortcuts to the methods that do the real work.
Good call... this is a wise way to do it in order to make your structs/classes CLS-compliant (as operator overloads are only available in C# for .NET 1.x, while both C# and VB.NET get the feature in 2.0), just in case some twisted individual wants to use your code from COBOL.NET or something equally freaky and wrong ;)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
