when is it ok to use a structure rather than a class

Question

In a recent project I was working I created a structure in my class to solve a problem I was having, as a colleague was looking over my shoulder he looked derisively at the structure and said "move it into a class".

I didn't have any argument for not moving it into a class other than I only need it in this class but this kind of falls down because couldn't I make it a nested class?

When is it ok to use a structure?

Answer 1

You should check out the value type usage guidelines: http://msdn.microsoft.com/en-us/library/y23b5415(vs.71).aspx

The article lists several important points but the few that I feel are the most valuable are the following

• Is the value immutable?
• Do you want the type to have value semantics?

If the answer to both questions is yes then you almost certainly want to use a Structure. Otherwise I would advise going with a class.

There are issues with using structures with a large amount of members. But I find that if I consider the two points above, rarely do I have more than the recommended number of members / size in my value types.

Answer 2

MSDN has a good guidelines document to cover structure usage. To summarize:

• Act like primitive types.
• Have an instance size under 16 bytes.
• Are immutable.
• Value semantics are desirable.

Otherwise, use a class.

Answer 3

You should always use a Class as your first choice, changing to Structure only for very specific reasons (as others have already outlined).

Depending on how much you "only need it in this class", you might be able to avoid the nested type completely by using an anonymous type; this will only work within a single method:

Public Class Foo
    Public Sub Bar
     Dim baz = New With { .Str = "String", .I = 314 }
    End Sub
End Class

you can't (readily--there are a few things you can do with generics) move the instance baz outside of the Sub in a typesafe manner. Of course an Object can hold anything, even an instance of an anonymous type.

Answer 4

I think structures are great if you need copy the object or do not want it to be modified by the passed function. Since passed functions can not modify the originally passed structure instead got a new copy of it, this can be a life saver. (unless they passed as ByRef obviously) and can save you trouble of deep copy craziness in .NET or implementing pain of an ICloneSomething implementation.

But the general idea is defining a custom data structure in a more semantic way.

About moving to a class, if you are moving into a class where it'll be part of a class, generally this is good practice since your structure is 99% of the time related with one of you classes not related with a namespace.

If you are converting it to a class then you need to consider "is it defining a data strcuture" and "is it expensive?" since it's gonna be copied all over the place, "do you want to get affected by modifications done by the passers?"

Answer 5

The usage guidelines referenced by Marc and Rex are excellent and nicely cover cases where you aren't sure which one you would want. I will list some use cases where use of a struct is a requirement.

• When you need to set the layout of the fields in memory
  • Interop with unmanaged code.
  • When you want to make Unions.
• You need a fixed size buffer inlined.
• You want to be able to do the equivalent of a reinterpret_cast with relative safety (so long as the struct does not contain any fields which are themselves reference types.

These are normally edge cases and (with the exception of interop) not recommended practices unless their use is necessary for the success of the project/program.