C# Struct usage tips?

Question

I like using structs a lot.

So after reading this article, are there any other concerns I should have against using them all the time?

See Also:

• When should I use a struct instead of a class?
• When to use struct in C#?

Answer 1

They don't fit into an Object Oriented programming paradigm like classes do. They are good for small data structures, but I use classes for anything beyond that.

Answer 2

I think main purpose of a struct - to keep only variable types. If you keep some classes into struct - you're wrong.

Answer 3

Use of structs should be limited to when all you really need is a small data structure. (as you read). I would only really use them for the smallest of datastructures like coordinates, offsets, and sometimes for graphics.

In many ways, you can think of structs in C# as being like scaled - down classes. They are basically the same as classes but designed more for cases where you simply want to group some data together. They differ from classes in the following ways: Some things to keep in mind

• Structs are value types, not reference types. This means they are stored either in the stack or in- line (if they are part of another object that is stored on the heap) and have the same lifetime re-strictions as the simple data types.
• Structs do not support inheritance.
• There are some differences in the way constructors work for structs. In particular, the compiler always supplies a default no - parameter constructor, which you are not permitted to replace.

Answer 4

Ask yourself the following questions about the set of data you're modeling with a struct:

• Might it ever need to have any get/set logic?
• Might it ever need to store ANY logic that is endemic to the data?
• Might it need to inherit another set of data?
• Might another set of data need to inherit this one?

I think if you can heartily answer "no" to all these questions, then there's no good reason not to use a struct. I think people use static subclasses in certain situations where a struct would be more than good enough.

Answer 5

I almost never define custom structs. There just aren't that many natural value types around, IMO.

In particular, I would think very, very carefully before defining a mutable struct, especially if it mutates via an interface implementation. Mutable structs behave in ways which people don't expect at all, leading to code which is hard to understand.

I think it's worth reading "Choosing Between Classes and Structures" from "Design Guidelines For Developing Class Libraries".

In particular:

Do not define a structure unless the type has all of the following characteristics:

• It logically represents a single value, similar to primitive types (integer, double, and so on).

• It has an instance size smaller than 16 bytes.

• It is immutable.

• It will not have to be boxed frequently.

Do you really develop types with all of those characteristics frequently?

Answer 6

You should make the following considerations about structs:

• structs should be immutable (mutable structs are not intuitive and unpredictable)
• structs always have a default (public parameterless) constructor that cannot be changed
• struct size should not exceed 16 bytes
• the Equals and GetHashCode methods should be overriden for better performance
• implementing the IEquatable<T> interface is recommended
• redefining and == and the != operators is also recommended

Answer 7

A class is a lot simpler to implement correctly than a struct. If you implement a struct incorrectly it can give you some unexpected errors.

A struct should not be larger than 16 bytes, or you lose most of the performance benefits.

A struct is intended to be a value type, representing a single entity of some kind.

A struct should be immutable. That means that you never change one of the properties in a struct. If you want a struct value that is different you create a new value.