Considering struct limits

Structures are a value type, which means that C# allocates memory for them differently than classes. Most of the struct limits come from this difference. Here are some things to consider when you think about using a struct in place of a class. A structure

• Can have constructors, but not destructors. This means that you can perform all the usual tasks required to create a specific data type, but you don't have control over cleaning up through a destructor.
• Cannot inherit from other structures or classes (meaning they’re stand-alone).
• Can implement one or more interfaces, but with the limits imposed by the elements they support (see “Including common struct elements,” later in this chapter, for details).
• Cannot be defined as abstract, virtual, or protected.

Understanding the value type difference

When working with structures, you must remember that they're a value type, not a reference type like classes. This means that structures have certain inherent advantages over classes. For example, they’re much less resource intensive. In addition, because structures aren’t garbage-collected, they tend to require less time to allocate and deallocate.

The differences in resource use and in both allocation and deallocation time is compounded when working with arrays. An array of reference types incurs a huge penalty because the array contains just pointers to the individual objects. To access the object, the application must then look for it on the heap.

Value types are also deterministic. You know that C# deallocates them the moment they go out of scope. Waiting for C# to garbage-collect reference types means that you can’t quite be sure how memory is used in your application.

Determining when to use struct versus class

Opinions abound as to when to use a struct versus a class. For the most part, it all ends up being a matter of what you're trying to achieve and what you’re willing to pay in terms of both resource usage and application speed to achieve it. In most cases, you use class far more often than you use struct simply because class is more flexible and tends to incur fewer penalties in some situations.

As with all value types, structures must be boxed and unboxed when cast to a reference type or when required by an interface they implement. Too much boxing and unboxing will actually make your application run slower. This means that you should avoid using structures when you need to perform tasks with reference types. In this case, using a class is the best idea.

Using a value type also changes the way in which C# interacts with the variable. A reference type is passed by reference during a call so that any changes made to the reference type appear in all instances that point to that reference. A value type is copied when you pass it because it's passed by value. This means that changes you make to the value type in another method don’t appear in the original variable. This is possibly the most confusing aspect of using structures for developers because passing an object created by a class is inherently different from passing a variable created by a structure. This difference makes classes generally more efficient to pass than structures.

It’s true that structures do have a definite advantage when working with arrays. However, you must exercise care when working with structures in collection types because the structure may require boxing and unboxing. If a collection works with objects, you need to consider using a class instead.

Avoid using structures when working with objects. Yes, you can place object types within a structure, but then the structure will contain a reference to the object, rather than the object itself. References reduce the impact of any resource and time savings that a structure can provide. Keep structures limited to other value types such as int and double when possible. Of course, many structures still use reference types such as String.

Defining a basic struct

A basic struct doesn't contain much more than the fields you want to use to store data. For example, consider a struct used to store messages from people requesting the price of certain products given a particular quantity. It might look like this (also found in the BasicStruct example in the downloadable source):

public struct Message
{
public int MsgID;
public int ProductID;
public int Qty;
public double Price;
}

To use this basic structure, you might follow a process like this:

static void Main(string[] args)
{
// Create the struct without new.
Message myMsg;
// Or, create it with new.
//Message myMsg = new Message();

// Create a message.
myMsg.MsgID = 1;
myMsg.ProductID = 22;
myMsg.Qty = 5;

// Compute the price.
myMsg.Price = 5.99 * myMsg.Qty;

// Display the struct on screen.
Console.WriteLine(
$"In response to Msg {myMsg.MsgID}, you can get {myMsg.Qty} " +
$"of {myMsg.ProductID} for ${myMsg.Price}.");
Console.ReadLine();
}

Note that the process used to create and use a structure is much the same as creating and using a class. In fact, you could possibly look at the two processes as being the same for the most part (keeping in mind that structures do have differences). For example, you can create a struct without using new as shown in the code, which is a benefit when structs are used in an array from a performance perspective. If you create a struct without using new, then you must initialize the fields before you use them. The output from this example looks like this:

In response to Msg 1, you can get 5 of 22 for $29.95.

Obviously, this is a simplified example, and you'd never create code like this for a real application, but it does get the process you use across. When working with structures, think about the processes you use with classes, but with a few differences that can make structures far more efficient to use.

Including common struct elements

Structures can include many of the same elements as classes do. The “Defining a basic struct” section of the chapter introduces you to the use of fields. As previously noted, fields cannot be abstract, virtual, or protected. However, their default scope is private, and you can set them to public, as shown in the code. Obviously, classes contain far more than fields and so do structures. The following sections use the StructWithElements example to take you through the common struct elements so that you can use structures efficiently in your code.

Using supplemental struct elements

The “Including common struct elements” section, earlier in this chapter, discusses elements that you commonly use with both classes and structures to perform essential tasks. The ColorList example found in the following sections describes some supplemental elements that will enhance your use of structures.

Managing a single record

Passing structures to methods is cleaner and easier than passing individual data items. Of course, the values in the structure must be related in order for this strategy to work well. However, consider the following method:

static void DisplayMessage(Message msg)
{
Console.WriteLine(
$"In response to Msg {myMsg.MsgID}, you can get {myMsg.Qty} " +
$"of {myMsg.ProductID} for ${myMsg.Price}.");
}

In this case, the DisplayMessage() method receives a single input of type Message instead of the four variables that the method would normally require. Using the Message structure produces these positive results in the code:

• The receiving method can assume that all the required data values are present.
• The receiving method can assume that all the variables are initialized.
• The caller is less likely to create erroneous code.
• Other developers can read the code with greater ease.
• Code changes are easier to make.

Adding structures to arrays

Applications rarely use a single data record for every purpose. In most cases, applications also include database-like collections of records. For example, an application is unlikely to receive just one Message. Instead, the application will likely receive a group of Message records, each of which it must process.

You can add structures to any collection. However, most collections work with objects, so adding a structure to them would incur a performance penalty because C# must box and unbox each structure individually. As the size of the collection increases, the penalty becomes quite noticeable. Consequently, it's always a better idea to restrict collections of data records that rely on structures to arrays in your application when speed is the most important concern.

Working with an array of structures is much like working with an array of anything else. You could use code like this to create an array of Message structures:

// Display all the messages on screen.
Message[] Msgs = { myMsg, myMsg2 };
DisplayMessages(Msgs);

In this case, Msgs contains two records, myMsg and myMsg2. The code then processes the messages by passing the array to DisplayMessages(), which is shown here:

static void DisplayMessages(Message[] msgs)
{
foreach (Message item in msgs)
{
Console.WriteLine(
$"In response to Msg {myMsg.MsgID}, you can get {myMsg.Qty} " +
$"of {myMsg.ProductID} for ${myMsg.Price}.");
}
}

The DisplayMessages() method uses a foreach loop to separate the individual Message records. It then processes them using the same approach as DisplayMessage() in the previous section of the chapter.

Overriding methods

Structures provide a great deal of flexibility that many developers assign exclusively to classes. For example, you can override methods, often in ways that make the structure output infinitely better. A good example is the ToString() method, which outputs a somewhat unhelpful (or something similar):

Structures.Program+Messages

The output isn't useful because it doesn’t tell you anything. To garner anything useful, you must override the ToString() method by using code like this:

public override string ToString()
{
// Create a useful output string.
return "Message ID: " + MsgID +
" Product ID: " + ProductID +
" Quantity: " + Qty +
" Total Price: " + Price;
}

Now when you call ToString(), you obtain useful information. In this case, you see the following output when calling myMsg.ToString():

Message ID: 1
Product ID: 22
Quantity: 5
Total Price: 29.95

Comparing records to structures and classes

As previously mentioned, a record is a combination of a structure and a class with a little secret sauce added so that you experience the delicious taste of records without the coding. A record has these properties:

• The ability to define immutable properties so that a record is more secure than either a structure or class.
• A record uses value equality so that two records with the same structure and the same properties are the same. This differs from a class, which depends on reference equality (looking for pointers to the same memory location).
• You can use non-destructive mutation to create a new record (with different property values) based on an existing record. To perform this task, you use the with expression.
• Unlike many other C# objects, the record provides a ToString() method that displays:
  • The record type name
  • The names and values of public properties
• A record is a kind of class under the covers, so, unlike a structure, it supports inheritance hierarchies.

Working with a record

A record can look remarkably similar to a structure, except for the use of the record keyword, as shown here:

public record Person
{
public string First { get; set; }
public string? Middle { get; set; }
public string Last { get; set; }
public int? Age { get; set; }
}

The question marks after the type declaration for the Middle and Age properties means that these properties are nullable. You'll see how this works to your advantage a little later in this section. However, for now, try this code to work with the structure:

static void Main(string[] args)
{
Person ThisPerson = new Person()
{
First = "Amanda",
Middle = null,
Last = "Langley",
Age = null
};

Console.WriteLine(ThisPerson.ToString());
Console.ReadLine();
}

Unlike classes and structures, a record provides the means to print itself out in a meaningful way through the ToString() method. Here’s the default output you see:

Person { First = Amanda, Middle = , Last = Langley, Age = }

However, you likely want to add a ToString() method, especially if you have nullable properties. The following ToString() method makes use of the nullable Age value to determine what to print:

public override string ToString()
{
if (Age.HasValue)
return $"{Last}, {First} {Middle} Age: {Age}";
else
return $"{Last}, {First} {Middle} Age Withheld";
}

Notice the use of the HasValue property to determine whether Age is null. The output now looks like this:

Langley, Amanda
Age Withheld

Using the positional syntax for property definition

Records provide a level of flexibility in declaration that you don't find with classes or structures. For example, you can create a positional declaration with relative ease, as shown here:

public record Person2(string First, string Middle, string Last, int? Age)
{
public override string ToString()
{
if (Age.HasValue)
return $"{Last}, {First} {Middle} Age: {Age}";
else
return $"{Last}, {First} {Middle} Age Withheld";
}
}

This code is significantly shorter than the declaration in the previous section, yet it does the same thing with a little twist. You can now create the record using a shorter syntax as well:

Person2 NextPerson = new("Andy", "X", "Rustic", 42);

The record is instantiated on a single line without writing any code for a special constructor. The point is that you waste a lot less time writing code, yet get flexible records for data processing.

Understanding value equality

Like a structure, a record compares the kind of record and the values it contains when making an equality decision. This means that you can compare two different records quickly and easily. Here is an example of how this comparison works:

Person2 ThirdPerson = new("Andy", "X", "Rustic", 42);
Console.WriteLine($"NextPerson == ThirdPerson: " +
$"{NextPerson == ThirdPerson}");
Console.WriteLine($"ReferenceEquals(NextPerson, ThirdPerson): " +
$"{ReferenceEquals(NextPerson, ThirdPerson)}");

When you run this code, you see the following output:

NextPerson == ThirdPerson: True
ReferenceEquals(NextPerson, ThirdPerson): False

NextPerson and ThirdPerson are two completely different objects. However, you can compare them to verify that they contain the same record using the == operator. If this were a class, you'd need to compare the value of each property individually, which is time consuming and error prone.

Creating safe changes: Nondestructive mutation

There are times when two records might be almost the same, but just a little different. In such a case, you can mutate a current record into a new record using this technique:

Person2 FourthPerson = ThirdPerson with { Age = null };
Console.WriteLine(FourthPerson);

In this case, FourthPerson would be just like ThirdPerson, but with a different Age property value. When you run this code, you see the following output:

Rustic, Andy X
Age Withheld

Using the field keyword

The get; set; syntax used by auto-implemented properties is fine as long as you don't need to do anything other than get or set a value. Otherwise, you need to create a backing field and add a lot more code to your properties. C# 10.0 introduces the field keyword to reduce or eliminate the use of backing fields. For example, in the following record, it’s possible to ensure that Department is stored in uppercase without resorting to the use of a backing field:

public record Person
{
public string First { get; set; }
public string? Middle { get; set; }
public string Last { get; set; }
public int? Age { get; set; }
public string Department { get; set => field = value.ToUpper(); }
}

This feature only works if you configure your project to use C# 10.0 in the .csproj file like this:

<PropertyGroup>
<LangVersion>10.0</LangVersion>
</PropertyGroup>

The field keyword makes it easy to keep things short and simple. You can use it with get;, set;, and init; as needed. Don’t worry if you can’t fit what you need on a single line. You can use an extended version like this as well:

public record Person
{
public string First { get; set; }
public string? Middle { get; set; }
public string Last { get; set; }
public int? Age { get; set; }
public string Department { get;
set
{
if (value.Trim() == "")
throw new ArgumentException("No blank strings");
field = value.ToUpper();
}
}
}

This second form still doesn’t require the use of a backing field, and it tends to be shorter than the older version of the code. The point is that you shouldn’t have to use backing fields very often anymore with C# 10.0 and the .NET 6.0 framework (it doesn’t work with .NET 5.0).