Reference Types vs Value Types

1. Introduction

Imagine you have a box. If it's a box that actually contains the item itself (like a box with an apple inside), that's like a value type. The data itself is right there in the "box" (the variable).

On the other hand, imagine you have a business card with an address on it. The card itself isn't a house, it just points to where the house is. That's like a reference type. In this case, the variable doesn't hold the data itself, but a "business card"—an address in memory where the data lives.

Simple examples:

• int x = 5; // Value type: variable x "stores" the number 5 directly.
• string name = "Vasya"; // Reference type: variable name "stores" a reference to the string "Vasya", which is somewhere in memory.

Who's who in this world?

To help you get your bearings, here's a general list of which main data types belong to which category:

• Primitive types: int, double, float, bool, char, byte, short, long, decimal, etc.
• Structs (struct): All custom structs you declare using the struct keyword.
• Enums (enum): Types that let you define a set of named constants.

• Strings (string): Even though strings have some quirks (they're immutable), they're reference types.
• All arrays: For example, int[], string[], YourCustomClass[].
• All classes (class): All custom classes you declare with the class keyword.
• Delegates (delegate): Types that represent references to methods.
• Interfaces (interface): While interfaces themselves aren't objects, a variable of interface type can hold a reference to an object that implements that interface.
• Lists, dictionaries, and other collections: For example, List<T>, Dictionary<TKey, TValue>.
• Basically, anything that's not a struct or enum is a reference type by default in C#.

2. Copying Variables

This is where the main practical difference comes in. When you assign one variable to another, what actually gets copied?

A) Copying a value type (Value Type)

When you copy a value type, you get a full, independent copy of the data itself. It's like making a photocopy of a document: changes to one copy don't affect the original or any other copies.

    int a = 10;
int b = a; 					// b is now also 10, but it's "its own copy"
Console.WriteLine($"Initial values: a = {a}, b = {b}"); // Initial values: a = 10, b = 10

b = 15; 					// Change b
Console.WriteLine($"After changing b: a = {a}, b = {b}"); // After changing b: a = 10, b = 15

Explanation: Variable b got its own copy of the value 10. When b was changed to 15, a kept its original value 10. They're totally independent.

B) Copying a reference type (Reference Type)

When you copy a reference type, you only copy the reference—the "address" of the object in memory. Both variables now point to the same object. It's like giving two people the same business card: they both know the address of the same house. If one person paints the wall, the other will see the change when they visit.

Let's look at arrays as an example, since they're a super clear way to see "reference magic" (unlike strings, which have their own quirks).

int[] arr1 = {1, 2, 3};
int[] arr2 = arr1; // arr2 and arr1 point to the same array in memory!

// Initial values: arr1[0] = 1, arr2[0] = 1
Console.WriteLine($"Initial values: arr1[0] = {arr1[0]}, arr2[0] = {arr2[0]}"); 

arr2[0] = 42; // Change array element via arr2

// After changing arr2[0]: arr1[0] = 42, arr2[0] = 42
Console.WriteLine($"After changing arr2[0]: arr1[0] = {arr1[0]}, arr2[0] = {arr2[0]}"); 

Explanation: Both variables (arr1 and arr2) hold a reference to the same array in memory. When you change arr2[0], you're actually changing the array both variables point to. So arr1[0] also shows the changed value.

String Quirk (string)

Strings in C# are reference types, but they act a bit differently because they're immutable. That means once a string is created, you can't change it. Any operation that seems to "change" a string (like concatenation, Replace()) actually creates a new string in memory.

string str1 = "Hello";
string str2 = str1; // str2 points to the same "Hello" object as str1

// str1 = "Hello", str2 = "Hello"
Console.WriteLine($"Initial values: str1 = \"{str1}\", str2 = \"{str2}\""); 

str2 = "Bye"; // This creates a NEW "Bye" object, and str2 now points to it

// str1 = "Hello", str2 = "Bye"
Console.WriteLine($"After changing str2: str1 = \"{str1}\", str2 = \"{str2}\""); 

Explanation: At first, str1 and str2 both pointed to the same "Hello" object. When str2 was assigned "Bye", C# didn't change the existing "Hello" object. Instead, it created a new "Bye" object in memory, and str2 now points to that. str1 still points to the old "Hello" object. This is a key difference that often trips up beginners.

3. Table of Main Differences

4. Example in an App

Let's say we're building a simple console app for a user questionnaire. We have a struct for exam scores and a class for the user profile.

// Value type: struct for storing scores
struct Score
{
    public int Points;
    public string Grade; // Added for clarity
}

// Reference type: class for user profile
class User
{
    public string Name;
    public Score ExamScore; // Nested struct
}

Copying a struct (Score)

Score score1 = new Score { Points = 100, Grade = "A" };
Score score2 = score1; // All contents of score1 are copied to score2
Console.WriteLine($"score1: Points={score1.Points}, Grade={score1.Grade}"); // score1: Points=100, Grade=A
Console.WriteLine($"score2: Points={score2.Points}, Grade={score2.Grade}"); // score2: Points=100, Grade=A

score2.Points = 88;
score2.Grade = "B";

Console.WriteLine("--- After changing score2 ---");
Console.WriteLine($"score1: Points={score1.Points}, Grade={score1.Grade}"); // score1: Points=100, Grade=A (didn't change!)
Console.WriteLine($"score2: Points={score2.Points}, Grade={score2.Grade}"); // score2: Points=88, Grade=B

Result: score1 stayed the same. That's because when you do Score score2 = score1;, the contents of score1 (all its fields) are copied into score2. Both variables now have their own independent sets of data.

Copying a class (User)

User u1 = new User 
{ 
    Name = "Anna", 
    ExamScore = new Score { Points = 95, Grade = "A" } 
};
User u2 = u1; // Now u2 and u1 both point to THE SAME user in memory!
Console.WriteLine($"u1: Name={u1.Name}, Score={u1.ExamScore.Points}"); // u1: Name=Anna, Score=95
Console.WriteLine($"u2: Name={u2.Name}, Score={u2.ExamScore.Points}"); // u2: Name=Anna, Score=95

u2.Name = "Ivan"; // Change name via u2
u2.ExamScore.Points = 60; // Change score via u2
u2.ExamScore.Grade = "C";

Console.WriteLine("--- After changing u2 ---");
Console.WriteLine($"u1: Name={u1.Name}, Score={u1.ExamScore.Points}, Grade={u1.ExamScore.Grade}"); // u1: Name=Ivan, Score=60, Grade=C
Console.WriteLine($"u2: Name={u2.Name}, Score={u2.ExamScore.Points}, Grade={u2.ExamScore.Grade}"); // u2: Name=Ivan, Score=60, Grade=C

Result: u1 changed too! That's because u1 and u2 both originally pointed to the same User object in memory. When we changed properties of the object via u2 (like u2.Name = "Ivan";), we actually changed the object itself. So when we access u1.Name, we see the changed value. Even the nested struct ExamScore changed for u1, because it's part of the User object both references point to.

5. What Happens When Passing to Methods

Understanding how types are passed to methods is super important for predictable program behavior.

Passing a value type (Value Type) to a method

When you pass a value type to a method by default, it's passed by value. That means the method gets a copy of the original variable. Any changes made inside the method to this copy don't affect the original outside the method.

void AddTen(int x)
{
    Console.WriteLine($"Inside method (before change): x = {x}"); // Inside method (before change): x = 5
    x = x + 10; // x is now 15, but it's a local copy
    Console.WriteLine($"Inside method (after change): x = {x}"); // Inside (after change): x = 15
    // This local copy 'x' "dies" after the method ends.
}

int num = 5;
Console.WriteLine($"Before calling method: num = {num}"); // Before calling method: num = 5
AddTen(num);
Console.WriteLine($"After calling method: num = {num}"); // After calling method: num = 5 (didn't change!)

Result: Variable num stayed the same (5). x inside AddTen is a totally separate variable, initialized with a copy of num's value.

Passing a reference type (Reference Type) to a method

When you pass a reference type to a method by default, it's also passed by value, but what's copied is the value of the reference, not the object itself. That means inside the method, you get a copy of the "business card" (address) to the original object. Both references (the original and the one inside the method) point to the same object in memory.

void RenameUser(User u)
{
    // Inside method (before change): u.Name = "Olga"
    Console.WriteLine($"Inside method (before change): u.Name = \"{u.Name}\""); 
    u.Name = "New name"; // Change property of the object 'u' points to
    // Inside method (after change): u.Name = "New name"
    Console.WriteLine($"Inside method (after change): u.Name = \"{u.Name}\""); 
}

User user = new User { Name = "Olga" };
// Before calling method: user.Name = "Olga"
Console.WriteLine($"Before calling method: user.Name = \"{user.Name}\""); 
RenameUser(user); 
// After calling method: user.Name = "New name"
Console.WriteLine($"After calling method: user.Name = \"{user.Name}\""); 

Result: The user's name changed to "New name". The RenameUser method got a copy of the reference to the user object. Through this reference copy, the method could access the original object in the heap and change its Name property.

Important note: What happens if, inside the method, we assign a new object to the reference type parameter?

void ReassignUser(User u)
{
    u = new User { Name = "Totally new user" }; // 'u' now points to a new object
    Console.WriteLine($"Inside method (after reassignment): u.Name = \"{u.Name}\"");
}

User originalUser = new User { Name = "Original user" };
Console.WriteLine($"Before calling ReassignUser: originalUser.Name = \"{originalUser.Name}\"");
ReassignUser(originalUser); 
Console.WriteLine($"After calling ReassignUser: originalUser.Name = \"{originalUser.Name}\""); // "Original user" - didn't change!

Result: originalUser didn't change! That's because ReassignUser got a copy of the reference. When u = new User(...) happened inside the method, the local variable u started pointing to a totally new object. The original reference originalUser still points to the same old object. This is a super important point!

6. "Beginner Tears": Common Mistakes and Why They Happen

Understanding reference and value types can be tricky for beginners. Here are some common mistakes and misconceptions:

Mixing up array copying: Beginners often expect that doing arr2 = arr1; will create an independent copy of the array. Actually, that's just two references to the same array. It's like two controllers for the same game: whatever you do on one controller affects the game, and you'll see it on the other controller too. To make an independent copy of an array, you need to explicitly clone it (like int[] arr2 = (int[])arr1.Clone(); or use Copy methods).

Expecting strings to change "by reference": Because string is a reference type, sometimes people think it'll behave like an array when it comes to changing it. But because of immutability, any operation that seems to change a string actually creates a new string object. This often leads to unexpected results and can be inefficient if you're doing lots of string operations in a loop (for that, use StringBuilder).

Forgetting about null: Value types, except for nullable types (int?, bool?), always have some value and can never be null. Reference types can be null, meaning they don't point to any object. Trying to access a member of an object that's null will cause the infamous NullReferenceException. Always check reference variables for null before using them if there's a chance they might be undefined.

Using classes instead of structs for small data: Sometimes people just default to using classes for everything. For small, simple sets of data that represent a single thing (like a point Point { X, Y }, color Color { R, G, B }), structs can be more efficient since they're stored on the stack and copied by value, which reduces garbage collection overhead. But structs should be immutable, small, and shouldn't contain reference types that themselves can be null or change state.

2

Task

C# SELF, level 12, lesson 3

Locked

Array behavior as a reference type

Array behavior as a reference type

Open

2

Task

C# SELF, level 12, lesson 3

Locked

Interacting with Methods for Value and Reference Types

Interacting with Methods for Value and Reference Types

Open