Classes vs. Structs: Reference and Value Semantics

1. The Two Memory Arenas: Stack and Heap

Every C# program manages its memory in two primary areas: the stack and the heap. Understanding their roles is the first step to understanding classes and structs. The stack is an efficient, ordered region of memory, while the heap is a more flexible, but less structured, pool.

The following video provides an excellent visual and conceptual breakdown of these two memory regions and how they operate.

To summarize the key points from the video:

• The Stack: Operates in a Last-In, First-Out (LIFO) manner. It's used for storing local variables and parameters for your methods. When a method is called, a "stack frame" containing its local data is pushed onto the stack. When the method returns, that frame is popped off. This process is extremely fast and automatic.
• The Heap: A large, general-purpose memory area for objects whose lifetime isn't tied to a single method call. Allocation on the heap is more complex than on the stack. The Garbage Collector (GC) is the system responsible for automatically finding and freeing up memory on the heap that is no longer being used.

2. The Two Kinds of Types: Value vs. Reference

Now, let's connect these memory concepts to C# types. Every type in C# is either a value type or a reference type. This classification dictates how they are stored in memory and how they behave during assignment.

• struct (and primitive types like int, double, bool) are value types.
• class (and other types like string, arrays, delegates) are reference types.

The article below provides a crisp definition of these two categories.

This distinction is the core of what we're learning today. Let's make it concrete:

Value Semantics (struct)

A variable of a value type directly contains its data. If it's a local variable, its data lives on the stack. When you assign one value-type variable to another, the data is copied. Each variable has its own independent copy.

Reference Semantics (class)

A variable of a reference type doesn't hold the data itself. Instead, it holds a reference (think of it as a memory address or a pointer) to an object living on the heap. When you assign one reference-type variable to another, only the reference is copied, not the object's data. Both variables now point to the exact same object on the heap.

This diagram perfectly illustrates the concept:

3. Seeing it in Action: Code and Memory

Let's observe this behavior with code. The difference between copying a value and copying a reference has profound implications for how your program works.

First, let's look at a straightforward code comparison.

To see this happening in a more dynamic way, the following video uses a debugger to visualize the memory allocations as the code runs.

The key takeaway is this: because multiple variables can refer to the same class instance, a change made through one variable is visible to all others. With structs, a change made to a copy is isolated to that copy. This is the essence of reference versus value semantics.

4. The "Why": Performance and Design Implications

You're a developer who wants to know not just how things work, but why you should choose one approach over another. The choice between class and struct is a fundamental design decision with significant performance trade-offs.

Allocation, Garbage Collection, and Cache Locality

As you saw, classes are allocated on the heap. Creating thousands or millions of small objects can put pressure on the Garbage Collector, which periodically has to pause execution to clean up unused memory. Structs, especially when used as local variables or in arrays, can avoid this overhead.

The next video segment uses a benchmark to demonstrate this effect. The performance difference can be dramatic.

The video highlights several advantages for structs in this scenario:

1. Fewer Allocations: An array of one million structs is a single, contiguous block of memory on the heap. An array of one million classes involves one million and one allocations: one for the array of references, and one for each object on the heap.
2. Less GC Pressure: Fewer objects on the heap means less work for the GC.
3. Better Cache Locality: Since the struct data is contiguous in the array, iterating over it is very CPU-cache-friendly. The CPU can pre-fetch memory efficiently. With the class array, the data is scattered across the heap, leading to potential cache misses as the CPU jumps from reference to object.

The Trade-Offs: Copying Cost and Boxing

This performance gain doesn't come for free. Structs have two main performance pitfalls:

1. Copying Cost: Because value types are copied on assignment or when passed to methods, large structs can be expensive. Copying a class reference is always cheap (just copying a memory address, typically 8 bytes), but copying a 64-byte struct means moving all 64 bytes. For this reason, a common guideline is to keep structs small, often suggested as under 16 bytes.

2. Boxing: This is a crucial concept. Boxing is the process of converting a value type instance into a reference type object. This happens when you, for example, cast a struct to object or to an interface it implements. The runtime allocates a "box" on the heap, copies the struct's data into it, and gives you a reference to the box. This completely negates the performance benefits of using a struct, as it introduces a heap allocation and GC pressure.

The NDepend blog has a clear example of boxing in action.

5. Making the Right Choice: A Practical Framework

So, with these trade-offs in mind, how do you decide? Here is a practical framework to guide your design choices.

The following reading synthesizes all these concepts into an actionable checklist and provides excellent, concrete examples of good and bad usage.

Here is a summary of the decision-making process:

Default to class. It is the standard, most flexible choice in object-oriented programming. Only choose struct if you have a specific, well-understood reason.

Consider using a struct when your type:

• Logically represents a single, simple value (e.g., a point, a color, a range).
• Is small (generally under 16 bytes).
• Is immutable (its state doesn't change after creation). You should almost always declare structs as readonly struct to enforce this.
• Will not be frequently boxed.

You should definitely use a class when your type:

• Has identity. This is a critical concept. If two instances with the same data are still considered distinct entities (like two Customer objects who happen to have the same name), you need a class. Reference equality naturally models identity.
• Is large or has a state that will be modified after creation.
• Needs to participate in an inheritance hierarchy. Structs do not support inheritance.

Conclusion

In this lesson, we've unpacked the fundamental difference between classes and structs in C#. You learned that this distinction is rooted in their memory behavior—classes as reference types on the heap, and structs as value types stored in-place.

Here are the key takeaways:

• Classes follow reference semantics: variables hold a reference to a shared object on the heap. Copying the variable copies the reference.
• Structs follow value semantics: variables hold the data directly. Copying the variable copies the data, creating an independent instance.
• This leads to a performance trade-off: classes have GC overhead but cheap reference copies, while structs avoid GC pressure but incur costs for copying data and can suffer from boxing.
• The choice between them is a deliberate design decision. Use class by default, and struct for small, immutable, value-like types where performance benefits are clear.

In our next lesson, we will explore records. Records are a modern C# feature that builds directly on these concepts. They are specialized classes or structs designed to make creating immutable, data-focused types incredibly simple and robust. This will be your next step in mastering modern C# class design.