C# Struct vs Class: A Comprehensive Guide

By /

Okay, here’s a comprehensive guide to C# Structs vs. Classes, aiming for the 5000-word target. This will be a deep dive, covering fundamental concepts, detailed comparisons, performance implications, best-practice guidelines, and numerous illustrative examples.

C# Struct vs Class: A Comprehensive Guide

In the world of C#, understanding the distinction between struct (structures) and class (classes) is fundamental to writing efficient, well-structured, and maintainable code. Both are user-defined data types, serving as blueprints for creating objects, but they differ significantly in their underlying behavior, memory management, and intended use cases. This guide provides an in-depth exploration of these differences, equipping you with the knowledge to choose the right tool for the job.

1. Fundamental Concepts: Defining Structures and Classes

Both structs and classes allow you to encapsulate data (fields) and behavior (methods, properties, events, etc.) into a single unit. They support object-oriented principles like encapsulation, inheritance (for classes), and polymorphism (for classes, through interfaces).

1.1. Structs (Structures)

A struct is a value type. This means that when you assign a struct variable to another, a copy of the data is made. Structs are typically used to represent lightweight objects, often containing related data elements.

“`csharp
public struct Point
{
public int X;
public int Y;

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

public void Translate(int dx, int dy)
{
    X += dx;
    Y += dy;
}

}
“`

Key characteristics of structs:

  • Value Type: The core defining feature. Copying a struct creates a new, independent instance.
  • Stack Allocation (Usually): Structs are typically allocated on the stack, leading to faster allocation and deallocation compared to classes. (There are exceptions, discussed later).
  • No Inheritance: Structs cannot inherit from other structs or classes (except implicitly from System.ValueType). They also cannot be inherited from.
  • Implicit Parameterless Constructor: Structs always have a default parameterless constructor that initializes all fields to their default values (e.g., 0 for integers, false for booleans, null for reference types). You can’t define a custom parameterless constructor without also defining other constructors. If you define any constructor, you must initialize all fields.
  • Sealed: Structs are implicitly sealed, meaning they cannot be used as a base type.
  • No Finalizers (Destructors): Structs cannot have finalizers.
  • Interfaces: Structs can implement interfaces.

1.2. Classes

A class is a reference type. When you assign a class variable to another, you are copying a reference to the same object in memory. Changes made through one variable will be reflected in the other.

“`csharp
public class Person
{
public string Name { get; set; }
public int Age { get; set; }

public Person(string name, int age)
{
    Name = name;
    Age = age;
}

public void Introduce()
{
    Console.WriteLine($"Hello, my name is {Name} and I am {Age} years old.");
}

}
“`

Key characteristics of classes:

  • Reference Type: Copies are references to the same object in memory.
  • Heap Allocation: Classes are allocated on the managed heap. This involves garbage collection for deallocation.
  • Inheritance: Classes support inheritance, allowing you to create hierarchies of classes with shared properties and behaviors.
  • Customizable Parameterless Constructor: You can define a custom parameterless constructor.
  • Can be Abstract or Sealed: Classes can be declared abstract (cannot be instantiated directly, must be inherited from) or sealed (cannot be inherited from).
  • Finalizers (Destructors): Classes can have finalizers (using the ~ClassName() syntax) to release unmanaged resources.
  • Interfaces: Classes can implement interfaces.

2. Value Types vs. Reference Types: The Core Distinction

The most critical difference between structs and classes lies in their fundamental nature as value types and reference types, respectively. This difference permeates nearly every aspect of their behavior.

2.1. Value Types (Structs)

  • Copy Semantics: When you assign a struct to another variable, a complete copy of the struct’s data is created. The two variables are entirely independent.
  • Stack Allocation (Typically): Value types are often stored on the stack, a region of memory that is managed automatically by the system. Stack allocation is very fast, as is deallocation (which happens automatically when the variable goes out of scope).
  • Immutability Benefits (Recommended, Not Enforced): While structs can be mutable (their fields can be changed), it’s generally best practice to design them as immutable. Immutability simplifies reasoning about your code and avoids unexpected side effects. Creating copies ensures that modifications don’t inadvertently affect other parts of your program.
  • Boxing and Unboxing: When a value type (like a struct) is used in a context that requires a reference type (e.g., passed as an object parameter), a process called boxing occurs. The value type is “boxed” into an object on the heap, and a reference to that object is used. Retrieving the value from the boxed object is called unboxing. Boxing and unboxing have performance overhead.

Example (Value Type Copying):

“`csharp
Point p1 = new Point(10, 20);
Point p2 = p1; // p2 is a copy of p1

p2.X = 30;

Console.WriteLine($”p1.X: {p1.X}, p1.Y: {p1.Y}”); // Output: p1.X: 10, p1.Y: 20
Console.WriteLine($”p2.X: {p2.X}, p2.Y: {p2.Y}”); // Output: p2.X: 30, p2.Y: 20
// Changes to p2 do not affect p1.
“`

2.2. Reference Types (Classes)

  • Reference Semantics: When you assign a class instance to another variable, you are copying a reference to the same object in memory. Both variables point to the same underlying data.
  • Heap Allocation: Reference types are allocated on the managed heap, a region of memory that is managed by the garbage collector (GC). The GC periodically identifies objects that are no longer referenced and reclaims their memory.
  • Mutability: Classes are often designed to be mutable (their state can change). This is a natural consequence of reference semantics.
  • No Boxing/Unboxing Overhead (Directly): Reference types are already stored on the heap, so no boxing is required when they are used in contexts requiring objects.

Example (Reference Type Copying):

“`csharp
Person person1 = new Person(“Alice”, 30);
Person person2 = person1; // person2 now refers to the same object as person1

person2.Age = 35;

Console.WriteLine($”person1.Age: {person1.Age}”); // Output: person1.Age: 35
Console.WriteLine($”person2.Age: {person2.Age}”); // Output: person2.Age: 35
// Changes to person2 do affect person1 because they point to the same object.
“`

3. Memory Management: Stack vs. Heap

Understanding the memory allocation differences between structs and classes is crucial for performance tuning.

3.1. The Stack

  • Fast Allocation/Deallocation: The stack is a LIFO (Last-In, First-Out) data structure. Allocation and deallocation are extremely fast, involving simple pointer adjustments.
  • Limited Size: The stack has a limited size (typically a few megabytes). Stack overflow errors occur if you try to allocate too much data on the stack (e.g., through deep recursion or large structs).
  • Automatic Management: The system automatically manages the stack. You don’t need to explicitly allocate or deallocate memory.
  • Scope-Based Lifetime: Variables on the stack have a lifetime tied to their scope (the block of code in which they are defined). When the scope ends, the memory is automatically reclaimed.

3.2. The Managed Heap

  • Slower Allocation/Deallocation: Heap allocation is more complex than stack allocation, involving searching for a suitable block of memory. Deallocation is handled by the garbage collector, which can introduce pauses in your application’s execution.
  • Larger Size: The heap is much larger than the stack, allowing for the allocation of large objects and data structures.
  • Garbage Collection: The garbage collector (GC) automatically reclaims memory that is no longer in use. This prevents memory leaks, but it also introduces overhead.
  • Reference-Based Lifetime: Objects on the heap live as long as there are references to them. When all references are gone, the object becomes eligible for garbage collection.

3.3. Structs and the Heap: The Exceptions

While structs are typically allocated on the stack, there are important exceptions:

  • Structs as Members of Classes: If a struct is a field within a class, the struct’s data is stored as part of the class object on the heap.
  • Structs as Elements of Arrays: When structs are stored in an array, the array itself is allocated on the heap, and the struct data is stored contiguously within the array’s memory block.
  • Boxing: As mentioned earlier, boxing a struct creates a copy of the struct’s data on the heap.
  • Captured Variables in Closures: If a struct is captured by a lambda expression or anonymous method (a closure), it may be allocated on the heap to ensure its lifetime extends beyond the scope of the method where it was declared.
  • Iterators: When structs are used with yield return in an iterator, the state of the iterator is often stored on the heap.

Example (Struct as a Class Member):

“`csharp
public class Rectangle
{
public Point TopLeft; // Point is a struct
public Point BottomRight; // Point is a struct

public Rectangle(Point topLeft, Point bottomRight)
{
    TopLeft = topLeft;
    BottomRight = bottomRight;
}

}

// …
Rectangle rect = new Rectangle(new Point(0, 0), new Point(10, 10));
// rect is on the heap, and the Point structs are stored within rect’s memory.
“`

4. Performance Considerations

The choice between structs and classes can have significant performance implications, especially in performance-critical sections of your code.

4.1. Structs: Potential Performance Benefits

  • Faster Allocation/Deallocation (Stack): Stack allocation is significantly faster than heap allocation. This can be a major advantage in scenarios involving frequent creation and destruction of small objects.
  • Reduced Garbage Collection Pressure: Because structs are often allocated on the stack, they don’t contribute to the workload of the garbage collector. This can reduce GC pauses and improve overall application responsiveness.
  • Cache Locality: Structs stored contiguously in memory (e.g., in an array) can exhibit better cache locality. This means that accessing one element of the struct is likely to bring nearby elements into the CPU cache, leading to faster subsequent accesses.
  • No Indirection: Accessing a struct’s fields is direct, as there’s no need to follow a reference.

4.2. Structs: Potential Performance Drawbacks

  • Copying Overhead: Copying large structs can be expensive, as it involves copying all the data. This overhead can outweigh the benefits of stack allocation, especially if the structs are frequently passed as arguments to methods.
  • Boxing Overhead: Boxing and unboxing operations have performance costs. If you frequently need to use structs in contexts requiring reference types, the overhead can become significant.

4.3. Classes: Potential Performance Benefits

  • Efficient Passing by Reference: Passing large objects by reference (as classes are) is very efficient, as only the reference needs to be copied, not the entire object.
  • Shared State: If multiple parts of your code need to access and modify the same data, using a class can avoid the need for repeated copying.

4.4. Classes: Potential Performance Drawbacks

  • Heap Allocation Overhead: Heap allocation is slower than stack allocation.
  • Garbage Collection Overhead: The garbage collector introduces overhead, which can lead to pauses in your application.
  • Indirection: Accessing a class member involves following a reference, which can be slightly slower than direct access (although modern CPUs often optimize this).

4.5. Benchmarking

It’s essential to benchmark your code to measure the actual performance impact of using structs vs. classes in specific scenarios. Don’t rely solely on theoretical considerations; empirical evidence is crucial. Tools like BenchmarkDotNet can help you create reliable benchmarks.

5. Inheritance and Polymorphism

5.1. Classes and Inheritance

Classes support inheritance, a powerful mechanism for code reuse and creating hierarchical relationships between types. A derived class (subclass) inherits the members (fields, methods, properties, etc.) of its base class (superclass) and can extend or modify them.

“`csharp
public class Animal
{
public string Name { get; set; }

public virtual void MakeSound()
{
    Console.WriteLine("Generic animal sound");
}

}

public class Dog : Animal
{
public override void MakeSound()
{
Console.WriteLine(“Woof!”);
}
}

public class Cat : Animal
{
public override void MakeSound()
{
Console.WriteLine(“Meow!”);
}
}
“`

5.2. Classes and Polymorphism

Polymorphism (“many forms”) allows you to treat objects of different classes in a uniform way, based on their shared base class or interface. This is typically achieved through virtual methods and overriding.

“`csharp
Animal[] animals = new Animal[] { new Dog(), new Cat() };

foreach (Animal animal in animals)
{
animal.MakeSound(); // Calls the appropriate MakeSound method for each animal
}
// Output:
// Woof!
// Meow!
“`

5.3. Structs and Inheritance/Polymorphism
Structs do not support inheritance. They cannot inherit from other types, nor can they be inherited from. Because of this, you can not use virtual or abstract methods, which are crucial for polymorphism.

5.4 Structs and Interfaces
Although structs do not support inheritance, they do support interfaces. This allows a form of polymorphism where a struct can “act like” different types through implemented interfaces. However, keep in mind that boxing will occur when using a struct through its interface reference.

“`csharp
public interface IMovable
{
void Move(int distance);
}

public struct Car : IMovable
{
public int Position {get; private set;}

public void Move(int distance)
{
    Position += distance;
    Console.WriteLine($"Car moved {distance} units.");
}

}
“`

6. Mutability vs. Immutability

6.1. Mutable Objects

Mutable objects can have their state (their fields) changed after they are created. Classes are typically designed to be mutable, although you can create immutable classes.

6.2. Immutable Objects

Immutable objects cannot have their state changed after they are created. Any operation that appears to modify an immutable object actually creates a new object with the modified state. Structs are often designed to be immutable, and this is generally recommended.

6.3. Benefits of Immutability

  • Thread Safety: Immutable objects are inherently thread-safe, as they cannot be modified by multiple threads concurrently.
  • Easier Reasoning: Immutable objects simplify reasoning about your code, as you don’t need to worry about unexpected state changes.
  • Reduced Side Effects: Immutability reduces the risk of unintended side effects, making your code more predictable and maintainable.
  • Caching: Immutable objects can be safely cached, as their values will never change.

6.4. Creating Immutable Structs

To create an immutable struct:

  • Make all fields readonly.
  • Initialize all fields in the constructor.
  • Avoid methods that modify the struct’s state. Instead, return new struct instances with the modified values.

“`csharp
public readonly struct ImmutablePoint // use the readonly modifier
{
public readonly int X; // readonly fields
public readonly int Y;

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

public ImmutablePoint Translate(int dx, int dy)
{
    return new ImmutablePoint(X + dx, Y + dy); // Return a *new* instance
}

}
“`

6.5 readonly struct vs struct

C# 7.2 introduced the readonly struct modifier. Applying this modifier enforces immutability at the compiler level. The compiler will generate errors if you attempt to modify any fields of a readonly struct after its construction, even within its own methods (except for constructors).

The readonly modifier on a struct declaration implies that every instance field of the struct is implicitly readonly. This is the recommended way to create immutable structs in modern C#. It’s more concise and provides stronger compile-time guarantees.

6.6 ref readonly Returns and Locals

C# 7.2 also added ref readonly returns and locals. This allows methods to return a read-only reference to a struct. This avoids copying the struct, while still ensuring that the caller cannot modify it. This is useful for performance optimization when working with large structs.

“`csharp
public readonly struct LargeStruct
{
public readonly long Value1;
public readonly long Value2;
// … many more fields …

public LargeStruct(long v1, long v2 /* ... */) {
    Value1 = v1;
    Value2 = v2;
    // ...
}

}

public class StructHolder
{
private LargeStruct _myStruct = new LargeStruct(1, 2 / … /);

public ref readonly LargeStruct GetLargeStruct()
{
    return ref _myStruct; // Return a read-only reference
}

}

// …
StructHolder holder = new StructHolder();
ref readonly LargeStruct large = ref holder.GetLargeStruct(); // Get the read-only reference
// large.Value1 = 10; // Error! Cannot modify a readonly reference
Console.WriteLine(large.Value1); // Allowed to read the value.

“`

7. Default Values and Initialization

7.1. Structs and Default Values

Structs have an implicit parameterless constructor that initializes all fields to their default values:

  • Numeric types: 0
  • bool: false
  • char: \0
  • Reference types: null
  • Struct types: Each field is initialized to its default value, recursively.

7.2. Classes and Default Values

Class fields are also initialized to their default values if no explicit initializer is provided. However, you can define a custom parameterless constructor for a class.

7.3. Struct Constructors

  • Implicit Parameterless Constructor: Always exists, even if you define other constructors. You cannot override it.
  • Custom Constructors: If you define any custom constructor for a struct, you must initialize all fields within that constructor.
  • No this Constructor Chaining before Field Initialization: In a struct constructor, you cannot use this(...) to chain to another constructor before all fields have been assigned a value.

“`csharp
public struct MyStruct
{
public int X;
public int Y;

// Valid constructor
public MyStruct(int x, int y)
{
    X = x;
    Y = y;
}

// Also Valid:
public MyStruct(int x)
{
   X = x;
   Y = 0; // Must initialize ALL fields.
}

// Invalid - you can't define a parameterless constructor that does nothing
// public MyStruct() { }

// Invalid, no initialization
//public MyStruct(int x)
//{
//    X = x;
//    // Y is not initialized!
//}

 // Invalid - can't chain before initializing fields
//public MyStruct(int x) : this(x, 0)
//{
//    X = x + 1;
//}

}
“`

8. When to Use Structs (Best Practices)

Use structs when your type meets all of the following criteria:

  1. Represents a Single Value: Logically represents a single value, similar to primitive types (e.g., int, double, bool). Examples: Point, Color, Rectangle, Vector3.
  2. Small Size: Has an instance size of under 16 bytes (ideally). Larger structs can lead to performance issues due to copying overhead. This is a general guideline and not a hard limit.
  3. Immutability: Will be commonly treated as immutable, or is best designed as immutable.
  4. Frequent Copying: Will not be frequently boxed or passed as arguments to methods by value if it’s a larger struct. Frequent copying of large structs can negate the benefits of stack allocation.

Good Examples of Structs:

  • Geometric Types: Point, Rectangle, Color, Vector2, Vector3, Quaternion, Matrix4x4.
  • Numeric Types: Custom numeric types (e.g., ComplexNumber, RationalNumber).
  • Data Transfer Objects (DTOs) (Small): Small, simple DTOs used for transferring data between layers or systems.
  • Enumeration Keys (Sometimes): Structs can be used as keys in dictionaries, but be mindful of boxing if you use the struct type directly as the key type. Using IEquatable<T> and providing a custom GetHashCode() implementation can help avoid boxing.
  • Keys in Collections (Carefully): Structs used as keys in dictionaries or hash sets should implement IEquatable<T> and override GetHashCode() and Equals() to ensure proper equality comparisons and avoid unnecessary boxing.
  • Represnting small data structures: A small structure that represents a key-value pair, or date-time information.

9. When to Use Classes (Best Practices)

Use classes in most other cases, especially when:

  1. Represents an Entity: Represents an entity with an identity and a lifecycle (e.g., Person, Customer, Order, Product).
  2. Large Size: Has a large instance size (greater than 16 bytes, as a guideline).
  3. Mutability: Needs to be mutable (its state needs to change over time).
  4. Inheritance/Polymorphism: Requires inheritance or polymorphism.
  5. Shared State: Represents data that needs to be shared and modified by multiple parts of your code.
  6. Long-Lived Objects: Represents objects that are expected to have a long lifespan.
  7. Resource Management: Needs to manage unmanaged resources (in which case you should implement IDisposable and potentially a finalizer).
  8. Represents Complex Operations: Represents complex operations or algorithms.
  9. Framework Requirements: Many .NET framework classes and libraries are built around classes.

Good Examples of Classes:

  • Business Entities: Customer, Order, Product, Employee.
  • UI Controls: Button, TextBox, Window.
  • Data Access Objects (DAOs): Objects that encapsulate database interactions.
  • Service Classes: Classes that provide services or perform specific tasks.
  • Event Handlers: Event handlers are typically methods within classes.
  • Collections: Lists, Dictionaries, etc., are all reference types.

10. in Parameters (Read-Only References)

C# 7.2 introduced in parameters, which provide a way to pass structs to methods by reference without allowing the method to modify the struct. This combines the efficiency of passing by reference with the safety of immutability.

“`csharp
public readonly struct Point3D
{
public readonly double X;
public readonly double Y;
public readonly double Z;

public Point3D(double x, double y, double z)
{
    X = x;
    Y = y;
    Z = z;
}

}

public static class GeometryUtils
{
// Use ‘in’ to pass by read-only reference
public static double Distance(in Point3D p1, in Point3D p2)
{
// p1.X = 10; // Error! Cannot modify an ‘in’ parameter

    double dx = p1.X - p2.X;
    double dy = p1.Y - p2.Y;
    double dz = p1.Z - p2.Z;

    return Math.Sqrt(dx * dx + dy * dy + dz * dz);
}

}

// …
Point3D point1 = new Point3D(1, 2, 3);
Point3D point2 = new Point3D(4, 5, 6);

double distance = GeometryUtils.Distance(point1, point2); // No copying of Point3D
“`

Key Points about in Parameters:

  • Efficiency: Avoids copying the struct, especially beneficial for large structs.
  • Read-Only: The compiler enforces read-only access within the method.
  • Defensive Copy (Sometimes): The compiler may create a defensive copy of the struct if it cannot guarantee that the method will not modify it (e.g., if you call a method on the in parameter that isn’t marked as readonly). This is to ensure that the original struct is never modified. This defensive copy, although rare, is something to be aware of.
  • Can be used with Classes: Though most beneficial with structs, in parameters can also be used with classes. This provides an explicit indication that the method will not modify the object. This is mostly useful for documentation and clarity.

11. ref struct (Stack-Only Structs)

C# 7.2 also introduced ref struct, a more restrictive type of struct that must be allocated on the stack. ref struct types have the following restrictions:

  • Cannot be boxed: You cannot convert a ref struct to object, ValueType, or any interface type.
  • Cannot be a field of a class: ref struct types cannot be used as fields within classes.
  • Cannot be used in iterators or async methods: ref struct types cannot be used in yield return statements or in async methods.
  • Cannot be captured by lambda expressions: You can’t capture a ref struct in a closure.
  • Cannot be an array element type: You cannot create an array of ref struct

These restrictions guarantee that a ref struct instance will always be allocated on the stack and will never outlive its scope. ref struct is primarily used for performance-critical scenarios, particularly when working with Span<T> and ReadOnlySpan<T>.

“`csharp
public ref struct MyRefStruct
{
public int Value;
}

// …
MyRefStruct myRef = new MyRefStruct();
// object obj = myRef; // Error! Cannot box a ref struct
// MyRefStruct[] array = new MyRefStruct[10]; // Error! ref struct cannot be an array element.

public class MyClass
{
//public MyRefStruct myField; // Error! ref struct cannot be a field of a class.
}
``SpanandReadOnlySpanare themselvesref struct` types and represent a contiguous region of memory. They provide a safe and efficient way to work with arrays, strings, and other memory buffers without copying the data.

12. Structs and Interfaces: Boxing Considerations

When a struct implements an interface, and you use the struct through the interface, boxing occurs. This is because interfaces are reference types.

“`csharp
public interface IMyInterface
{
void DoSomething();
}

public struct MyStruct : IMyInterface
{
public int Value;
public void DoSomething()
{
Console.WriteLine(“Doing something…”);
}
}

// …
MyStruct myStruct = new MyStruct();
myStruct.DoSomething(); // No boxing, direct call

IMyInterface myInterface = myStruct; // Boxing occurs here!
myInterface.DoSomething(); // Call through the interface

object obj = myStruct; // Boxing also occurs here
“`

To avoid boxing in this situation:
1. Call struct members Directly: When possible call members using the struct variable directly.

  1. Generic Constraints: Define methods with a generic type constraint that is your struct type and the interface.

“`C#
public static void ProcessStruct(T theStruct) where T : struct, IMyInterface
{
theStruct.DoSomething(); // No boxing
}

ProcessStruct(myStruct);

“`

13. Equality Comparisons

13.1. Structs and Equality

By default, structs use value equality. Two structs are considered equal if all their corresponding fields are equal. This equality check is done using bitwise comparison for simple value types, and recursively for nested structs.
“`csharp
public struct Point
{
public int X;
public int Y;
}
Point p1 = new Point { X = 10, Y = 20 };
Point p2 = new Point { X = 10, Y = 20 };
Point p3 = new Point { X = 15, Y = 25 };

Console.WriteLine(p1.Equals(p2)); // True, value equality.
Console.WriteLine(p1 == p2); // True, using the overloaded == operator (if defined), otherwise does a field-by-field comparison.
Console.WriteLine(p1.Equals(p3)); // False
“`

13.2. Classes and Equality

Classes, by default, use reference equality. Two class variables are considered equal only if they refer to the same object in memory.

“`csharp
public class Person
{
public string Name { get; set; }
}

Person person1 = new Person { Name = “Alice” };
Person person2 = new Person { Name = “Alice” };
Person person3 = person1;

Console.WriteLine(person1.Equals(person2)); // False, different objects (unless Equals is overridden)
Console.WriteLine(person1 == person2); // False, different objects (unless == is overridden)
Console.WriteLine(person1.Equals(person3)); // True, same object
Console.WriteLine(person1 == person3); // True, same object
“`

13.3. Overriding Equals and GetHashCode

For classes, you often want to define value equality based on the object’s data, rather than its reference. To do this, you should:

  • Override Equals(object obj): Provide a custom implementation that compares the relevant fields.
  • Override GetHashCode(): Provide a custom implementation that returns a hash code based on the same fields used in Equals(). This is essential for using objects as keys in dictionaries and hash sets.
  • Implement IEquatable<T>: This is the recommended approach as it avoids boxing for structs.
  • Consider Overloading == and !=: For a more intuitive syntax, you can overload the equality operators.

“`csharp
public class Person : IEquatable
{
public string Name { get; set; }
public int Age { get; set; }

public override bool Equals(object obj)
{
    if (obj is Person other)
    {
        return Equals(other);
    }
    return false;
}

public bool Equals(Person other)
{
    return other != null && Name == other.Name && Age == other.Age;
}

public override int GetHashCode()
{
    return HashCode.Combine(Name, Age);
}

public static bool operator ==(Person left, Person right)
{
    return EqualityComparer<Person>.Default.Equals(left, right);
}

public static bool operator !=(Person left, Person right)
{
    return !(left == right);
}

}
“`

13.4 Overriding Equals and GetHashCode for Structs

Even though structs have default value equality, it’s often beneficial to override Equals and GetHashCode for structs, especially if:
* Performance: The default implementation uses reflection, which can be slow. A custom implementation can be significantly faster.
* Custom Equality Logic: You need to define equality based on a subset of fields or using custom comparison logic.
* Avoid Boxing with collections: Using your struct as a key in dictionaries or hash tables without custom GetHashCode and Equals will result in boxing.

“`C#
public struct ComplexNumber : IEquatable
{
public double Real { get; }
public double Imaginary { get; }

public ComplexNumber(double real, double imaginary)
{
    Real = real;
    Imaginary = imaginary;
}

public override bool Equals(object obj)
{
    return obj is ComplexNumber other && Equals(other);
}

public bool Equals(ComplexNumber other)
{
    return Real == other.Real && Imaginary == other.Imaginary;
}

public override int GetHashCode()
{
    return HashCode.Combine(Real, Imaginary);
}

  public static bool operator ==(ComplexNumber left, ComplexNumber right)
{
    return left.Equals(right);
}

public static bool operator !=(ComplexNumber left, ComplexNumber right)
{
    return !(left == right);
}

}

“`

14. Conclusion: Making the Right Choice

The choice between structs and classes in C# is a fundamental design decision that impacts performance, memory usage, and code maintainability. By understanding the core differences – value type vs. reference type, stack vs. heap allocation, mutability vs. immutability, and inheritance/polymorphism capabilities – you can make informed choices that lead to robust and efficient code. Remember these key takeaways:

  • Structs: Ideal for small, immutable, value-like types that represent single values.
  • Classes: Suitable for most other scenarios, especially for entities, mutable objects, and situations requiring inheritance or polymorphism.
  • Performance: Benchmark your code to determine the actual performance impact in your specific context.
  • readonly struct: Use this for immutable structs for compiler-enforced immutability.
  • in parameters: Use these to pass structs by read-only reference, avoiding copies.
  • ref struct: Use for stack-only structs in performance-critical, low

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top