Struct vs. Class in C#: A Deep Dive into Choosing the Right Type

In the C# language, developers frequently encounter two fundamental ways to define custom data structures: struct and class. While they might appear similar at first glance, especially for simple data holding, they represent fundamentally different concepts with profound implications for memory management, performance, and overall program behavior. Understanding the distinction between structs (value types) and classes (reference types) is not just academic; it’s crucial for writing efficient, robust, and correct C# code.

Choosing incorrectly can lead to subtle bugs, performance bottlenecks related to excessive memory allocation or copying, and unexpected behavior when data is shared or modified. This article provides an exhaustive exploration of structs and classes in C#, covering their core differences, underlying mechanisms, performance characteristics, and detailed guidelines on when to use each effectively.

Introduction: The Core Distinction
Value Types vs. Reference Types: The Foundation
- What are Value Types? (Structs, Enums, Primitives)
- What are Reference Types? (Classes, Interfaces, Delegates, Arrays, string)
- Memory Allocation: Stack vs. Heap
- Copying Behavior: Copy by Value vs. Copy by Reference
Key Differences Summarized (Table)
Detailed Breakdown of Differences
- Memory Allocation and Management
- Assignment and Parameter Passing
- Inheritance
- Nullability and Default Values
- Constructors (Parameterless and Custom)
- Mutability
- Method Calls (Virtual Dispatch)
- Equality Comparison
- Boxing and Unboxing
Performance Considerations
- Allocation Costs (Stack vs. Heap)
- Garbage Collection Impact
- Copying Overhead
- Cache Locality
- Boxing/Unboxing Penalties
When to Use struct
- Representing Simple, Lightweight Data Aggregates
- Logical Primitives
- Immutable Data Structures
- Value Semantics are Desired
- Performance-Critical Scenarios (with Caveats)
- Microsoft’s Guidelines
- The readonly struct Modifier
- The ref struct Modifier (Stack-Only Types)
- The record struct (C# 10+)
When to Use class
- Representing Complex Entities with Behavior
- Reference Semantics are Required (Sharing)
- Need for Inheritance Hierarchies
- Working with Large Amounts of Data
- Identity Matters More Than Value
- Framework Expectations (e.g., ORMs, DI Containers)
- The record class
Common Pitfalls and Best Practices
- The Danger of Mutable Structs
- The Problem with Large Structs
- Unnecessary Boxing and Unboxing
- Premature Optimization
- Forgetting Nullable<T>
Real-World Examples
- Struct Examples: Point, Color, DateTime, Guid, KeyValuePair<TKey, TValue>, Custom Money
- Class Examples: Customer, Order, HttpClient, Stream, Form, Custom UserService
Conclusion: Making the Informed Choice

1. Introduction: The Core Distinction

At the heart of the C# type system lies the fundamental division between value types and reference types. This isn’t just a C# feature; it’s a core concept in the .NET Common Language Runtime (CLR).

struct: Defines a value type. Variables of a struct type directly contain their data.
class: Defines a reference type. Variables of a class type store a reference (or pointer) to the location where their data is stored in memory.

This single difference ripples through nearly every aspect of how these types behave, from how they are stored in memory and copied to whether they support inheritance and how they interact with the garbage collector.

Think of it like this:

A struct variable is like having a physical object (e.g., a specific book) directly in your hands. If you give a copy to someone, they get a completely separate, identical book. Changes to their book don’t affect yours.
A class variable is like having a library card with the shelf number of a book. The card itself is small (the reference), but it points to the actual book (the object) on the library shelf. If you give a copy of the card to someone, you both now have references pointing to the same book. If one person writes notes in that book, the other person will see those notes when they use their card to access the book.

Understanding this core analogy is the first step toward mastering structs and classes.

2. Value Types vs. Reference Types: The Foundation

Let’s delve deeper into the characteristics that define value and reference types.

What are Value Types?

Value types derive directly or indirectly from System.ValueType, which itself inherits from System.Object. However, System.ValueType overrides key methods from System.Object to provide behavior suitable for value types (like value-based equality comparison by default).

Examples of value types in C#:

Structs: User-defined (struct Point { ... }) and built-in (System.Int32, System.Boolean, System.Double, System.Decimal, System.DateTime, System.Guid). Note that primitive types like int, bool, double are aliases for their corresponding struct types.
Enums: (enum Color { Red, Green, Blue }). Enums are implicitly value types.

Key Characteristics:

Direct Data Storage: Variables hold the actual data.
Memory Location: Typically allocated on the stack (for local variables and parameters within method calls), but can be embedded within heap-allocated objects (as fields of a class).
Copying: Assignment or passing as an argument creates a copy of the entire data.
Nullability: Cannot be null by default. Need Nullable<T> (or T?) to represent an absence of value.
Inheritance: Cannot inherit from other classes or structs (except implicitly from System.ValueType). Can implement interfaces.
Default Value: A “zeroed-out” state (e.g., 0 for numeric types, false for bool, null for any reference type fields within the struct).

What are Reference Types?

Reference types derive directly or indirectly from System.Object.

Examples of reference types in C#:

Classes: User-defined (class Customer { ... }) and built-in (System.Object, System.String, System.Exception, System.IO.Stream).
Interfaces: (interface ILogger { ... }). Variables of an interface type hold a reference to an object that implements the interface.
Delegates: (delegate int Comparison(T x, T y);). Hold references to methods.
Arrays: (int[] numbers, string[] names). Even arrays of value types are reference types.
string: Although string often behaves somewhat like a value type due to its immutability and operator overloading, it is fundamentally a reference type.
object: The ultimate base type for all other types.

Key Characteristics:

Reference Storage: Variables hold a reference (memory address) to the data.
Memory Location: The actual object data is always allocated on the managed heap. The reference itself might be on the stack (local variable) or heap (field of another object).
Copying: Assignment or passing as an argument copies only the reference, not the underlying object data. Multiple variables can point to the same object.
Nullability: Can hold the value null, indicating the variable does not currently refer to any object.
Inheritance: Can inherit from one base class (single implementation inheritance) and implement multiple interfaces.
Default Value: null.

Memory Allocation: Stack vs. Heap

This is one of the most critical distinctions impacting performance.

The Stack:
- A region of memory used for storing local variables, method parameters, and return addresses during method execution.
- Organized as a Last-In, First-Out (LIFO) structure.
- Allocation is extremely fast: simply involves adjusting a stack pointer.
- Deallocation is also extremely fast: happens automatically when a method returns and its stack frame is popped.
- Limited in size compared to the heap. Stack overflow errors occur if it’s exhausted (e.g., infinite recursion).
- Value types (structs) declared as local variables or method parameters are typically allocated on the stack.
The Managed Heap:
- A larger region of memory used for dynamic allocation of objects whose lifetime isn’t tied to a single method call.
- Allocation involves finding a suitable free block of memory, which is generally slower than stack allocation. Requires the CLR’s memory manager.
- Deallocation is managed by the Garbage Collector (GC). The GC periodically identifies objects on the heap that are no longer referenced by any part of the application and reclaims their memory. This process can introduce pauses (GC collections) in application execution.
- Reference type objects (class instances) are always allocated on the heap.
- Value types can also live on the heap if they are fields within a class object or if they are “boxed” (discussed later).

Copying Behavior: Copy by Value vs. Copy by Reference

This directly follows from the memory model:

Struct (Value Type) Copying:
“`csharp
struct Point { public int X; public int Y; }

Point p1 = new Point { X = 10, Y = 20 };
Point p2 = p1; // Creates a complete copy of p1’s data (X and Y)

p2.X = 100;

Console.WriteLine($”p1.X: {p1.X}”); // Output: p1.X: 10
Console.WriteLine($”p2.X: {p2.X}”); // Output: p2.X: 100
// p1 and p2 are independent instances. Modifying p2 does not affect p1.
`` Whenp2 = p1;executes, the values ofp1.Xandp1.Yare copied directly into the memory allocated forp2`.
Class (Reference Type) Copying:
“`csharp
class Person { public string Name; }

Person person1 = new Person { Name = “Alice” };
Person person2 = person1; // Copies the reference from person1 to person2

person2.Name = “Bob”;

Console.WriteLine($”person1.Name: {person1.Name}”); // Output: person1.Name: Bob
Console.WriteLine($”person2.Name: {person2.Name}”); // Output: person2.Name: Bob
// person1 and person2 refer to the same object on the heap. Modifying via person2 affects what person1 sees.
`` Whenperson2 = person1;executes, only the memory address stored inperson1is copied intoperson2. Both variables now point to the identicalPerson` object on the heap.

This difference is fundamental when passing arguments to methods or returning values. Passing a struct copies it; passing a class instance copies the reference.

3. Key Differences Summarized (Table)

Feature	`struct` (Value Type)	`class` (Reference Type)
Kind	Value Type	Reference Type
Inheritance	Implicitly from `System.ValueType`. Cannot inherit from other structs/classes. Can implement interfaces.	Can inherit from one base class. Can implement interfaces.
Memory Allocation	Typically Stack (if local/param), or Heap (if class field/boxed)	Always Heap (object data)
Variable Content	Actual data	Reference (address) to data on the heap
Assignment	Copies the entire instance data	Copies the reference only
Parameter Passing	Passes a copy of the instance (by value)	Passes a copy of the reference (by value)
Default Value	“Zeroed-out” state (0, false, etc.)	`null`
Nullability	Not nullable by default (use `Nullable<T>`)	Nullable by default
Parameterless Ctor	Implicitly provided (zeros fields). Can be explicitly defined (C# 10+). Before C# 10, explicit definition disallowed.	Implicitly provided (if no other ctors). Can always be explicitly defined.
Destructor (`~`)	Not allowed	Allowed (Finalizer)
Identity vs. Value	Primarily represents a value	Primarily represents an object with identity
Typical Use	Small, simple data aggregates, primitives, immutable values	Complex objects, entities, services, data needing sharing
GC Pressure	Generally lower (if stack-allocated)	Higher (heap allocation requires GC)

4. Detailed Breakdown of Differences

Let’s expand on the key differences highlighted above.

Memory Allocation and Management

Structs: When a method declares a local struct variable (Point p;), memory for that struct is often allocated directly within the method’s stack frame. This allocation is near-instantaneous. When the method exits, the stack frame is unwound, and the memory is automatically reclaimed, also instantaneously. No garbage collection is involved for stack-allocated structs. However, if a struct is a field of a class (class Shape { Point Center; }), the struct’s data is stored within the Shape object on the heap. When the Shape object is garbage collected, the embedded Point data is collected along with it.
Classes: When you create a class instance (Person p = new Person();), the new operator triggers heap allocation. The CLR finds space on the managed heap, initializes the object’s memory (clearing it and running constructors), and returns a reference (address) to that memory, which is stored in the variable p. This process is more complex and slower than stack allocation. The object remains on the heap until the GC determines it’s no longer reachable and collects it. This collection process can pause application threads.

Assignment and Parameter Passing

Structs: Because assignment copies the data, changes to one copy don’t affect the other. This “copy-by-value” behavior is crucial when passing structs to methods.
“`csharp
void ModifyPoint(Point pt) // pt is a copy of the original Point
{
pt.X = 1000;
// Modifying pt only affects the local copy within this method.
}

Point myPoint = new Point { X = 1, Y = 1 };
ModifyPoint(myPoint);
Console.WriteLine(myPoint.X); // Output: 1 (The original myPoint was not changed)
If you *want* to modify the original struct, you need to use `ref` or `out` parameters, which pass the struct *by reference* (passing a pointer to the original struct's memory location).csharp
void ModifyPointByRef(ref Point pt) // pt is a reference to the original Point
{
pt.X = 1000;
// Modifying pt does affect the original struct outside the method.
}

Point myPointRef = new Point { X = 1, Y = 1 };
ModifyPointByRef(ref myPointRef);
Console.WriteLine(myPointRef.X); // Output: 1000
“`
Classes: Assignment copies the reference. Parameter passing also copies the reference. This means the method receives a reference pointing to the same object on the heap as the caller.
“`csharp
void ModifyPerson(Person p) // p is a copy of the reference to the original Person
{
// p points to the SAME object as myPerson outside the method.
p.Name = “Charlie”;
}

Person myPerson = new Person { Name = “David” };
ModifyPerson(myPerson);
Console.WriteLine(myPerson.Name); // Output: Charlie (The original object was modified)
`` Note that the reference itself is passed by value. If you reassign the parameterpinside the method (p = new Person { Name = “Eve” };), this only changes the localpvariable within the method; it does not change themyPersonvariable in the calling code to point to the new "Eve" object. To change the caller's reference, you'd again needreforout`.

Inheritance

Structs: Cannot inherit from any class or struct other than System.ValueType. This restriction prevents complex inheritance hierarchies involving value types, simplifying their memory layout and behavior. However, structs can implement interfaces.
csharp interface ICoordinate { int X { get; } int Y { get; } } struct Point : ICoordinate // OK: Structs can implement interfaces { public int X { get; set; } public int Y { get; set; } } // struct Vector : Point { } // ERROR: Structs cannot inherit from other structs/classes
Classes: Fully support single implementation inheritance (inheriting from one base class) and multiple interface implementation. This allows for creating rich, polymorphic object models.
csharp class Shape { public virtual void Draw() { /* ... */ } } class Circle : Shape // OK: Classes can inherit from other classes { public double Radius { get; set; } public override void Draw() { /* Draw circle */ } }

Nullability and Default Values

Structs: A variable of a struct type always contains a value (its data). It cannot inherently be null. The default value of a struct variable (e.g., a field in a class that hasn’t been initialized, or an element in a new T[]) is an instance where all value-type fields are set to their default (0, false, etc.) and all reference-type fields (if any) are set to null.
csharp Point p; // p is not null. p.X is 0, p.Y is 0. // Point p_null = null; // ERROR: Cannot assign null to a non-nullable value type.
To represent the absence of a value for a struct, you must use the System.Nullable<T> struct, often written using the shorthand T?.
“`csharp
Point? nullablePoint = null; // OK
nullablePoint = new Point { X = 5, Y = 5 };

if (nullablePoint.HasValue) {
Point actualPoint = nullablePoint.Value;
Console.WriteLine(actualPoint.X); // Access the underlying value safely
}
* **Classes:** A variable of a class type can hold a reference to an object or it can hold `null`, indicating it doesn't refer to any object. The default value for a class variable is `null`.csharp
Person personRef = null; // OK
if (personRef != null) {
Console.WriteLine(personRef.Name); // Need null check before accessing members
}
`` C# 8 introduced nullable reference types to help manage nullability explicitly for reference types at compile time, but fundamentally, they can always benull` at runtime.

Constructors

Structs:
- Implicit Parameterless Constructor: Every struct always has an implicit, parameterless constructor that initializes its fields to their default values. You cannot prevent this constructor from existing (e.g., by making it private). Before C# 10, you could not explicitly declare your own parameterless constructor for a struct.
- Explicit Parameterless Constructor (C# 10+): Starting with C# 10, you can explicitly define a parameterless constructor for a struct. This allows you to set non-default initial values. However, the implicit one still exists conceptually for array initialization and default(T) expressions. If you define any constructor, you must explicitly initialize all fields within that constructor (unless using field initializers, also new in C# 10 for structs).
- Custom Constructors: Structs can always have constructors with parameters. If you define a constructor with parameters, you must initialize all instance fields within that constructor before it returns (unless using C# 10 field initializers).
  “`csharp
  struct Point
  {
  public int X;
  public int Y;
  
  // C# 10+ allows field initializers
  // public int Z = -1;
  
  // C# 10+ allows explicit parameterless constructor
  // public Point()
  // {
  // X = -1;
  // Y = -1;
  // }
  
  public Point(int x, int y)
  {
  X = x;
  Y = y;
  // Before C# 10, you MUST initialize all fields here if you define any constructor.
  // Z = 0; // If Z field existed and wasn’t initialized via field initializer
  }
  }
  Point p1 = new Point(); // Uses explicit parameterless ctor if defined (C# 10+), else implicit (zeros fields)
  Point p2 = default(Point); // Always zeros fields, regardless of explicit parameterless ctor
  Point p3 = new Point(5, 10); // Uses the custom constructor
  “`
Classes:
- Implicit Parameterless Constructor: If you do not define any constructors in a class, the compiler provides a public, parameterless constructor that calls the base class’s parameterless constructor.
- Explicit Constructors: You can define any number of constructors (parameterless or with parameters). If you define any constructor, the compiler no longer generates the implicit parameterless one. If you still need a parameterless constructor, you must define it explicitly. Fields not explicitly initialized in a constructor are automatically initialized to their default values (null for reference types, 0/false for value types).
  “`csharp
  class Person
  {
  public string Name;
  public int Age = 30; // Field initializer
  
  // If no other constructors were defined, a public Person() {} would be generated.
  
  public Person(string name) // Defining this removes the implicit parameterless ctor
  {
  Name = name;
  // Age will be 30 due to the initializer
  }
  
  public Person() // Explicit parameterless constructor needed if the above exists
  {
  Name = “Unknown”;
  // Age will be 30
  }
  }
  Person p1 = new Person(); // Uses explicit parameterless ctor
  Person p2 = new Person(“Alice”); // Uses constructor with parameter
  “`

Mutability

Structs: Structs can be mutable (their fields or properties can be changed after creation). However, mutable structs are generally considered harmful and should be avoided. Why? Because the copy-by-value semantics can lead to confusing behavior. When you pass a mutable struct to a method or retrieve it from a collection, you often get a copy. Modifying that copy doesn’t change the original, leading to bugs where changes seem to disappear.
“`csharp
// AVOID: Mutable struct
public struct MutablePoint { public int X; public int Y; }

public void Example() {
var list = new List();
list.Add(new MutablePoint { X = 1, Y = 1 });
```
// TRYING TO MODIFY - THIS IS A COMMON MISTAKE
// list[0].X = 100; // ERROR in older C# / WARNING: Modifies a *copy* returned by the indexer!

// Correct way (but awkward): Retrieve copy, modify copy, replace original
MutablePoint temp = list[0];
temp.X = 100;
list[0] = temp; // Put the modified copy back

Console.WriteLine(list[0].X); // Output: 100 (only if done the awkward way)
```
}
It's strongly recommended to make structs **immutable**: define their fields as `readonly` and provide values only through the constructor. Use `readonly struct` for extra safety.csharp
public readonly struct ImmutablePoint // Good practice
{
public int X { get; } // Readonly property (implicitly readonly field)
public int Y { get; }
```
public ImmutablePoint(int x, int y)
{
    X = x;
    Y = y;
}
```
}
`` * **Classes:** Classes are often mutable, and this is generally acceptable because reference semantics mean multiple variables point to the *same* instance. Modifying the object through one reference is visible through all other references. Immutability is still a valuable pattern for classes (likestring`), especially in multi-threaded scenarios or for creating predictable state, but mutability is common and expected for many class-based designs (e.g., entity objects, view models).

Method Calls (Virtual Dispatch)

Structs: Methods defined directly on a struct are typically called directly (non-virtually). However, if a struct implements an interface, calling a method through the interface reference usually involves boxing (creating a heap object copy) and virtual dispatch, which has a performance cost.
Classes: Support virtual, override, and abstract methods. Calls to virtual methods on class instances use virtual dispatch (looking up the correct method implementation in a virtual method table based on the object’s actual runtime type). This enables polymorphism but incurs a small performance overhead compared to direct calls.

Equality Comparison

Structs: By default, System.ValueType overrides Equals() to perform value equality comparison. It uses reflection to compare all instance fields of the two struct instances. While correct, reflection-based comparison can be slow. For performance-critical structs, it’s recommended to override Equals() (and GetHashCode()) yourself to perform direct field-by-field comparisons. Implementing IEquatable<T> is the preferred way.
“`csharp
public readonly struct Point : IEquatable
{
// … constructor …
public int X { get; }
public int Y { get; }
```
public bool Equals(Point other) // Specific, efficient comparison
{
    return X == other.X && Y == other.Y;
}

public override bool Equals(object obj) // Override object.Equals
{
    return obj is Point other && Equals(other);
}

public override int GetHashCode() // Must override if Equals is overridden
{
    return HashCode.Combine(X, Y); // Use System.HashCode helper
}

// Optional: Overload equality operators
public static bool operator ==(Point left, Point right) => left.Equals(right);
public static bool operator !=(Point left, Point right) => !left.Equals(right);
```
}
* **Classes:** By default, `System.Object.Equals()` performs **reference equality** comparison (checks if two variables refer to the exact same object instance on the heap). If you want value equality for a class (comparing the *contents* of the objects), you must override `Equals()` (and `GetHashCode()`) yourself. `record class` types override these automatically to provide value semantics.csharp
Person p1 = new Person { Name = “Alice” };
Person p2 = new Person { Name = “Alice” };
Person p3 = p1;

Console.WriteLine(p1.Equals(p2)); // Output: False (default reference equality)
Console.WriteLine(p1 == p2); // Output: False (default reference equality)
Console.WriteLine(p1.Equals(p3)); // Output: True (p1 and p3 refer to the same object)
Console.WriteLine(p1 == p3); // Output: True (p1 and p3 refer to the same object)
“`

Boxing and Unboxing

This is a crucial performance concept related to the value/reference type dichotomy.

Boxing: The process of converting a value type instance into a reference type (object or an interface type it implements). This involves:
1. Allocating memory on the managed heap.
2. Copying the value type’s data into the newly allocated heap memory.
3. Returning a reference to this heap object.
Unboxing: The process of converting a boxed value type (an object reference that actually points to a boxed value) back into its original value type. This involves:
1. Checking if the object reference actually points to a boxed instance of the correct value type.
2. Copying the data from the heap object back into a value type variable (usually on the stack).

Why does boxing happen? Often when you need to treat a value type polymorphically, for example:

Adding a struct to a non-generic collection like ArrayList (which stores objects).
Passing a struct to a method that accepts an object parameter (e.g., Console.WriteLine(myPoint)).
Casting a struct to an interface it implements (ICoordinate coord = myPoint;).

Performance Impact: Boxing requires heap allocation and data copying. Unboxing requires type checking and data copying. Both operations, especially if performed frequently in loops or performance-sensitive code, can significantly degrade performance and increase GC pressure due to the temporary heap objects created by boxing.

“`csharp
Point p = new Point(10, 20); // Struct on stack

// Boxing occurs here:
object obj = p; // Allocates heap memory, copies p’s data, obj holds reference

// Unboxing occurs here:
Point p2 = (Point)obj; // Checks type, copies data from heap back to stack variable p2

ArrayList list = new ArrayList();
list.Add(p); // Boxing occurs when adding the struct

ICoordinate coord = p; // Boxing occurs when casting to interface
“`

Using generic collections (List<Point>) and implementing generic interfaces (IEquatable<Point>) helps avoid unnecessary boxing.

5. Performance Considerations

The choice between struct and class significantly impacts performance characteristics.

Allocation Costs:
- Stack allocation (typical for local/param structs) is extremely fast.
- Heap allocation (classes, boxed structs) is significantly slower and involves the memory manager and potentially searching for free space. Frequent heap allocation increases GC pressure.
Garbage Collection Impact:
- Stack-allocated structs are cleaned up instantly when their scope ends, imposing no GC overhead.
- Heap-allocated objects (classes, boxed structs) persist until collected by the GC. Frequent creation of short-lived class instances puts pressure on the GC, potentially leading to more frequent and longer GC pauses, impacting application responsiveness.
Copying Overhead:
- Copying structs involves copying their entire data content. For large structs, this can be expensive, especially when passed frequently by value or stored in collections that make copies.
- Copying class references is very cheap (just copying a memory address, typically 4 or 8 bytes), regardless of the size of the object being referenced.
Cache Locality:
- Structs: Arrays of structs (Point[] points) store the struct data contiguously in memory. Accessing elements sequentially often benefits from CPU cache locality (data needed next is likely already loaded into the cache), which can significantly speed up processing.
- Classes: Arrays of classes (Person[] persons) store references contiguously. The actual Person objects are scattered across the heap. Accessing elements sequentially often leads to cache misses (data needs to be fetched from main memory), which is much slower.
Boxing/Unboxing Penalties:
- As discussed, boxing involves heap allocation and copying; unboxing involves type checks and copying. These operations are relatively expensive and should be minimized in performance-critical code paths.

General Performance Guideline:

Use structs for small, frequently created/destroyed data structures where value semantics are appropriate, especially if cache locality is beneficial (arrays of structs). Be mindful of copying costs if structs become large. Avoid boxing.
Use classes for larger, more complex objects, objects requiring identity or shared state, or when inheritance is needed. Be mindful of GC pressure if creating many short-lived instances.

6. When to Use `struct`

Based on the characteristics discussed, here are clear guidelines for choosing struct:

Represents a Single Value or Simple Aggregate: The type logically represents a single value, similar to primitive types (like int, double). Examples: Point, Color, ComplexNumber, Money, TimeSpan. It primarily acts as data holder with little or no complex behavior.
Small Instance Size: The struct has a small memory footprint. Microsoft documentation often suggests a guideline of 16 bytes or less, although this isn’t a strict rule. Smaller structs minimize copying overhead. You can estimate size based on field types (e.g., int=4 bytes, double=8 bytes, reference=4/8 bytes). Use tools like profilers or Marshal.SizeOf (with caveats) if precise size is critical. Large structs (> 16-32 bytes) can perform worse than classes due to copying costs.
Immutability is Desired: The value of the struct should not change after creation. Immutable structs avoid the pitfalls of mutable value types and work well with value semantics. Use readonly fields or properties with private set or init, and ideally mark the struct itself as readonly struct.
Value Semantics are Natural: You expect instances to be compared based on their content (data), not their identity (memory location). You expect assignment and parameter passing to create independent copies.
Boxing is Infrequent: You don’t anticipate the struct instances being frequently converted to object or interface types, which would negate performance benefits through boxing. Use generic collections (List<T>, Dictionary<TKey, TValue>) instead of non-generic ones (ArrayList, Hashtable).
Performance-Critical Scenarios (with Caveats): In scenarios involving tight loops, large arrays of data requiring cache locality, or minimizing GC pressure, structs can offer significant performance advantages if they meet the other criteria (small, immutable, value semantics, no boxing). Do not choose structs solely for performance without profiling; the overhead of copying large structs or unexpected boxing can make them slower than classes.

Microsoft’s Guidelines (Summarized):

✔️ CONSIDER defining a struct instead of a class if instances of the type are small and commonly short-lived or are commonly embedded in other objects.
✔️ DO use a struct for types that logically represent a single value, have a small instance size (e.g., under 16 bytes), are immutable, and will not need to be boxed frequently.
❌ AVOID defining a struct unless the type has all the characteristics of a value type (small, immutable, value semantics).
❌ AVOID using mutable structs.

The `readonly struct` Modifier

Introduced in C# 7.2, marking a struct with readonly enforces immutability at the compiler level.

All instance fields must be readonly.
Instance properties must be get-only (or have init accessors in C# 9+).
It prevents accidental mutation.
It can potentially improve performance by allowing the compiler to make stronger assumptions and avoid defensive copies in certain scenarios (e.g., when calling methods on a readonly struct instance).

“`csharp
public readonly struct ImmutablePoint // Strongly recommended for immutable structs
{
public int X { get; } // Must be readonly
public int Y { get; } // Must be readonly

public ImmutablePoint(int x, int y)
{
    X = x;
    Y = y;
}

// public void Mutate() { X = 0; } // ERROR: Cannot assign to readonly field X

}
“`

Use readonly struct whenever you design an immutable struct.

The `ref struct` Modifier (Stack-Only Types)

Introduced in C# 7.2, ref struct defines a struct type that is constrained to live only on the execution stack.

Cannot be boxed.
Cannot be stored as fields in a regular class or struct (only in other ref structs).
Cannot be captured in lambdas or async methods.
Cannot implement interfaces.
Cannot be used as type arguments in generics.

Why use them? They are primarily for performance-critical interop scenarios or specialized types like Span<T> and ReadOnlySpan<T>, which provide safe, high-performance access to contiguous memory regions (like arrays, strings, or native memory) without allocating on the heap or requiring copying.

“`csharp
public ref struct Span { / … internals … / }

int[] numbers = { 1, 2, 3, 4, 5 };
Span numberSpan = numbers; // Create a span over the array (no allocation)
Span slice = numberSpan.Slice(1, 3); // Slice [2, 3, 4] (no allocation)

slice[0] = 20; // Modifies the original array numbers[1]

// Span fieldInClass; // ERROR: Cannot use ref struct as field in class
// object boxedSpan = numberSpan; // ERROR: Cannot box ref struct
`` Useref struct` only for specific, low-level optimization or interop needs where stack allocation is mandatory.

The `record struct` (C# 10+)

C# 9 introduced record types (implicitly record class), providing concise syntax for immutable reference types with built-in value equality, ToString(), and deconstruction. C# 10 extended this to structs with record struct.

Defines a value type (struct).
Provides compiler-generated Equals(), GetHashCode(), and ToString() based on public members.
Supports concise “positional record” syntax for constructors, deconstructors, and properties.
Defaults to readonly unless specified otherwise (readonly record struct Point(...)).
Supports with expressions for non-destructive mutation (creates a new copy with modifications).

“`csharp
// Concise syntax for an immutable struct with value equality
public readonly record struct Point(int X, int Y);

// Usage:
Point p1 = new Point(10, 20);
Point p2 = p1 with { Y = 30 }; // Creates a new Point(10, 30)
Point p3 = new Point(10, 20);

Console.WriteLine(p1); // Output: Point { X = 10, Y = 20 } (Nice ToString)
Console.WriteLine(p1.Equals(p2)); // Output: False
Console.WriteLine(p1.Equals(p3)); // Output: True (Value equality)
Console.WriteLine(p1 == p3); // Output: True (Value equality)

var (x, y) = p1; // Deconstruction
“`

Use record struct when you need a small, immutable value type and want the convenience of compiler-generated members for equality, display, and non-destructive mutation. It’s an excellent choice for Data Transfer Objects (DTOs) or simple value representations that fit the struct criteria.

7. When to Use `class`

Classes remain the default choice for most custom types in C#. Use a class when:

Represents an Entity or Complex Object: The type represents an object with a distinct identity, potentially complex behavior (methods), and state that might change over time. Examples: Customer, Order, Window, FileStream, HttpClient.
Reference Semantics are Required: You want multiple variables to refer to the same instance, so changes made through one variable are visible through others. This is essential for sharing state or modeling relationships between objects.
Inheritance is Needed: You need to create inheritance hierarchies (e.g., Shape -> Circle, Square) or leverage polymorphism through virtual methods. Structs cannot participate in class inheritance hierarchies.
Instance Size is Large: The object contains a significant amount of data. Copying large structs frequently is inefficient; passing references to class instances is cheap regardless of object size. There’s no strict size threshold, but if a type exceeds ~32 bytes or contains many fields, a class is often more appropriate.
Object Identity is Important: You need to distinguish between two objects even if they contain the same data (e.g., two different Customer objects who happen to have the same name). Default class equality checks reference identity.
Lifetime Extends Beyond a Single Scope: The object needs to live longer than the method call that created it, requiring heap allocation managed by the GC.
Framework Expectations: Many frameworks (e.g., Entity Framework Core for database entities, ASP.NET Core Dependency Injection for services, UI frameworks like WinForms/WPF/MAUI for controls) are designed primarily to work with classes.
Nullable Representation is Natural: The concept of “not having an instance” (null) is a natural part of the type’s domain model.

The `record class`

Introduced in C# 9, record class (or just record) provides a concise way to define reference types that have built-in immutability features and value-based equality semantics.

Defines a reference type (class).
Compiler-generated Equals, GetHashCode, ToString.
Supports positional syntax and with expressions.
Primarily intended for immutable data carriers (like DTOs) where reference type behavior (e.g., nullability, potential sharing) is still desired or required by frameworks.

“`csharp
public record Person(string FirstName, string LastName); // Immutable record class

Person p1 = new Person(“John”, “Doe”);
Person p2 = p1 with { LastName = “Smith” }; // Non-destructive mutation
Person p3 = new Person(“John”, “Doe”);

Console.WriteLine(p1 == p2); // False (Value equality)
Console.WriteLine(p1 == p3); // True (Value equality)
`` Userecord classwhen you want the benefits of records (immutability, value equality) but still need a reference type (e.g., for compatibility with existing APIs, nullability, or very large data structures where copying would be prohibitive even withwith` expressions).

8. Common Pitfalls and Best Practices

The Danger of Mutable Structs: Avoid them. The combination of value-type copying and mutation leads to confusing bugs where changes are lost because they were made on a temporary copy. Always strive for immutable structs (readonly struct or record struct).
The Problem with Large Structs: Passing large structs by value or copying them frequently incurs significant performance overhead. Profile carefully; a class might be more efficient if the struct size becomes substantial.
Unnecessary Boxing and Unboxing: Be aware of operations that cause boxing (casting to object or interface, using non-generic collections). Use generic collections (List<T>) and implement generic interfaces (IEquatable<T>) to prevent boxing penalties.
Premature Optimization: Don’t choose struct just because you heard they are “faster” without understanding the context. Misusing structs (large size, frequent boxing, mutability) can hurt performance more than help. Profile your application to identify real bottlenecks before optimizing with structs. Classes are often the simpler, safer default.
Forgetting Nullable<T>: Remember that structs cannot be null. If you need to represent an optional or missing value for a struct type, use Nullable<T> or T?.

9. Real-World Examples

Let’s solidify the concepts with typical use cases:

Struct Examples:

System.DateTime, System.TimeSpan: Represent points or durations in time. Small, immutable, value semantics are natural.
System.Guid: Represents a globally unique identifier. Fixed size (16 bytes), immutable, value semantics.
System.Drawing.Point, System.Drawing.Color (Classic examples): Simple data aggregates representing coordinates or colors. Small, value semantics appropriate. Often better as readonly struct.
System.Collections.Generic.KeyValuePair<TKey, TValue>: Holds a key-value pair. Simple aggregate, often short-lived within enumeration loops.
decimal: High-precision number type. Behaves like a primitive, immutable, value semantics.
Custom Money Struct:
csharp public readonly record struct Money(decimal Amount, string Currency) { // Could add validation, formatting, operators... } // Represents a monetary value; small, immutable, value semantics desirable.

Class Examples:

System.IO.Stream, System.Net.Http.HttpClient: Represent resources (file handles, network connections) that have identity and state. Must be classes to manage the underlying resource lifetime and allow sharing.
System.Windows.Forms.Form, System.Windows.Controls.Button (UI Elements): Complex objects with identity, state, behavior (methods, events), and participate in inheritance hierarchies. Must be classes.
System.Text.StringBuilder: Represents a mutable string buffer. Needs reference semantics so modifications are reflected everywhere the buffer is used.
System.Collections.Generic.List<T>, Dictionary<TKey, TValue>: Collections manage references to other objects; they themselves have identity and state (count, capacity).
Custom Customer Class:
“`csharp
public class Customer
{
public int Id { get; set; }
public string Name { get; set; }
public List
Orders { get; } = new List
(); // Complex state
```
public void AddOrder(Order order) { /* Behavior */ }
// Represents a real-world entity with identity, potentially large state, and behavior.
```
}
* **Custom `UserService` Class:**csharp
public class UserService : IUserService // Often implements an interface for DI
{
private readonly IUserRepository _repo;
public UserService(IUserRepository repo) { _repo = repo; } // Dependencies
```
public User GetUser(int id) { /* Complex logic, interacts with repo */ }
// Represents a service with dependencies and complex behavior. Must be a class for DI and state management.
```
}
“`

10. Conclusion: Making the Informed Choice

Structs and classes are both essential tools in the C# developer’s toolkit, but they serve different purposes rooted in their fundamental nature as value types and reference types, respectively.

Classes are the workhorses for modeling complex objects, entities with identity, services, and scenarios requiring shared state or inheritance. Their reference semantics, heap allocation, and GC management are well-suited for larger, longer-lived objects with behavior. They are generally the default, safer choice when unsure.
Structs shine when representing small, simple, immutable values where copying is cheap and value semantics are desired. They can offer significant performance benefits by avoiding heap allocation and GC pressure and improving cache locality, especially when used correctly (small, immutable, no boxing). readonly struct and record struct make creating robust, efficient value types easier than ever.

The key takeaway is that the choice is not arbitrary. It has tangible consequences for performance, memory usage, and program correctness. By understanding the deep-seated differences in memory allocation, copying behavior, inheritance, nullability, and performance trade-offs, you can confidently select the right tool (struct or class) for the job, leading to cleaner, more efficient, and more maintainable C# applications. Always consider the logical representation, size, immutability, desired semantics, and potential performance implications when making your decision. When in doubt, start with a class, and only consider a struct if the specific criteria and potential benefits align with your goals, ideally backed by profiling data if performance is the primary driver.