C# / .NET : when structures are better than classes?

Question

Duplicate of: When to use struct in C#?

Are there practical reasons to use structures instead of some classes in Microsoft .NET 2.0/3.5 ?

"What is the difference between structures and classes?" - this is probably the most popular question on intrviews for ".NET developer" vacancies. The only answer that interviewer considers to be right is "structures are allocated on stack and classes are allocated on heap" and no further questions are asked about that.

Some google search showed that a) structures have numerous limitations and no additional abilities in comparison to classes and b) stack (and as such structures) can be faster on very specialized conditions including:

• size of data chunk less that 16 bytes
• no extensive boxing/unboxing
• structure's members are nearly immutable
• whole set of data is not big (otherwise we get stack overflow)

(please correct/add to this list if it is wrong or not full)

As far as I know, most typical commercial projects (ERM, accouting, solutions for banks, etc.) do not define even a single structure, all custom data types are defined as classes instead. Is there something wrong or at least imperfect in this approach?

NOTE: question is about run-of-the-mill business apps, please don't list "unusual" cases like game development, real-time animation, backward compatibility (COM/Interop), unmanaged code and so on - these answers are already under this similar question:

http://stackoverflow.com/questions/521298/when-to-use-struct-in-c

Answer 1

IMHO, structs are only used for performance improvement when you need a very small, simple value type.

Calls to members are also faster.

It might be also convenient when you don't need to care about references, and always get a new instance. This way, you never have side-effects when changing an instance which is referenced somewhere else. But this shouldn't be the main reason to use structs.

Answer 2

Another difference with classes is that when you assign an structure instance to a variable, you are not just copying a reference but indeed copying the whole structure. So if you modify one of the instances (you shouldn't anyway, since structure instances are intended to be immutable), the other one is not modified.

Answer 3

IMO the most important use case are large arrays of small composite entities. Imagine an array containing 10^6 complex numbers. Or a 2d array containing 1000x1000 24-bit RGB values. Using struct instead of classes can make a huge difference in cases like these.

EDIT: To clarify: Assume you have a struct

struct RGB 
{
   public byte R,G,B;
}

If you declare an array of 1000x1000 RGB values, this array will take exactly 3 MB of memory, because the values types are stored inline.

If you used a class instead of a struct, the array would contain 1000000 references. That alone would take 4 or 8 MB (on a 64 bit machine) of memory. If you initialized all items with separate objects, so you can modify the values separately, you'd habe 1000000 objects swirling around on the managed heap to keep the GC busy. Each object has an overhead (IIRC) of 2 references, i.e. the objects would use 11/19 MB of memory. In total that's 5 times as much memory as the simple struct version.

Answer 4

One advantage of stack allocated value types is that they are local to the thread. That means that they are inherently thread safe. That cannot be said for objects on the heap.

This of course assumes we're talking about safe, managed code.

Answer 5

sometime, you just wanna transfer data between components, then struct is better than class. e.g. Data Transfer Object(DTO) which only carry data.

Answer 6

As far as I know, most typical commercial projects (ERM, accouting, solutions for banks, etc.) do not define even a single structure, all custom data types are defined as classes instead. Is there something wrong or at least imperfect in this approach?

No! Everything is perfectly right with that. Your general rule should be to always use objects by default. After all we are talking about object-oriented programing for a reason and not structure-oriented programing (structs themselves are missing some OO principles like Inheritance and Abstraction).

However structures are sometimes better if:

• You need precise control over the amount of memory used (structures use (depending on the size) a little bit to FAR less memory than objects.
• You need precise control of memory layout. This is especially important for interop with Win32 or other native APIs
• You need the fastest possible speed. (In lots of scenarios with larger sets of data you can get a decent speedup when correctly using structs).
• You need to waste less memory and have large amounts of structured data in arrays. Especially in conjunction with Arrays you could get huge amount of memory savings with structures.
• You are working extensively with pointers. Then structures offer lots of interesting characteristics.

Answer 7

All good answers thus far...I only have to add that by definition value types are not nullable and hence are a good candidate for use in scenarios where you do not want to be bothered with creating a new instance of a class and assigning it to fields, for example...

struct Aggregate1
{
    int A;
}

struct Aggregate2
{
    Aggregate1 A;
    Aggregate1 B;
}

Note if Aggregate1 were a class then you would have had to initialize the fields in Aggregate2 manually...

Aggregate2 ag2 = new Aggregate2();
ag2.A = new Aggregate1();
ag2.B = new Aggregate1();

This is obviously not required as long as Aggregate1 is a struct...this may prove to be useful when you are creating a class/struct heirarchy for the express purpose of serialization/deserialization with the XmlSerializer Many seemingly mysterious exceptions will disappear just by using structs in this case.