Operators and Nullable Types

With simple types, such as int, you can use operators such as +, -, and so on to work with values. With nullable type equivalents, there is no difference: The values contained in nullable types are implicitly converted to the required type and the appropriate operators are used. This also applies to structs with operators that you have supplied:

int? op1 = 5;
int? result = op1 * 2;

Note that here the result variable is also of type int?. The following code will not compile:

int? op1 = 5;
int result = op1 * 2;

To get this to work you must perform an explicit conversion or access the value through the Value property, which requires code such as,

int? op1 = 5;
int result = (int)op1 * 2;

or:

int? op1 = 5;
int result = op1.Value * 2;

This works fine as long as op1 has a value — if it is null, then you will get an exception of type System.InvalidOperationException.

This raises the obvious question: What happens when one or both values in an operator evaluation that involves two nullable values are null, such as op1 in the following code?

int? op1 = null;
int? op2 = 5;
int? result = op1 * op2;

The answer is that for all simple nullable types other than bool?, the result of the operation is null, which you can interpret as “unable to compute.” For structs you can define your own operators to deal with this situation (as shown later in this chapter), and for bool? there are operators defined for & and | that might result in non-null return values. The results in the table make perfect sense logically — if there is enough information to work out the answer of the computation without needing to know the value of one of the operands, then it doesn't matter if that operand is null.

The ?? Operator

To further reduce the amount of code you need in order to deal with nullable types, and to make it easier to deal with variables that can be null, you can use the ?? operator. Known as the null coalescing operator, it is a binary operator that enables you to supply an alternative value to use for expressions that might evaluate to null. The operator evaluates to its first operand if the first operand is not null, or to its second operator if the first operand is null. Functionally, the following two expressions are equivalent:

op1 ?? op2
op1 == null ? op2 : op1

In this code, op1 can be any nullable expression, including a reference type and, importantly, a nullable type. This means that you can use the ?? operator to provide default values to use if a nullable type is null, as shown here:

int? op1 = null;
int result = op1 * 2 ?? 5;

Because in this example op1 is null, op1 * 2 will also be null. However, the ?? operator detects this and assigns the value 5 to result. Importantly, note here that no explicit conversion is required to put the result in the int type variable result. The ?? operator handles this conversion for you. Alternatively, you can pass the result of a ?? evaluation into an int? with no problems:

int? result = op1 * 2 ?? 5;

This behavior makes the ?? operator a versatile one to use when dealing with nullable variables, and a handy way to supply defaults without using either a block of code in an if structure or the often confusing ternary operator.

The ?. Operator

This operator, often referred to as the Elvis operator or the null condition operator, helps to overcome code ambiguity caused by burdensome null checking. For example, if you wanted to get the count of orders for a given customer, you would need to check for null before setting the count value:

int count = 0;
if (customer.orders ! = null)
{
  count = customer.orders.Count();
}

If you were to simply write this code and there were no orders existing for the customer (i.e. it's null), a System.ArgumentNullException is thrown:

int count = customer.orders.Count();

Using the ?. operator results in the int? count being set to null instead of an exception happening.

int? count = customer.orders?.Count();

Combining the null coalescing operator ?? discussed in the previous section with the null condition operator ?: makes it possible to set a default value when the result is null.

int? count = customer.orders?.Count() ?? 0;

Another use of the null conditional operator is to trigger events. Events are discussed in detail in Chapter 13. The most common way to trigger an event is by using this code pattern:

var onChanged = OnChanged;
if (onChanged != null)
{
  onChanged(this, args);
}

This pattern is not thread safe because someone might unsubscribe the last event handler just after the null check is done. When that happens an exception is thrown and the application crashes. Avoid this by using the null condition operator as shown here:

OnChanged?.Invoke(this, args);

As mentioned in Chapter 11, use the ?. operator to check for nulls with the == operator overload in the C:BegVCSharpChapter12Ch12CardLibCard.cs class to prevent an exception from being thrown when using the method. For example:

public static bool operator ==(Card card1, Card card2)
        => (card1?.suit == card2?.suit) && (card1?.rank == card2?.rank);

By including the null condition operator in the statement, you are effectively expressing that if the object to the left is not null, (in this case card1 or card2), then retrieve what is to the right. If the object on the left is null (i.e. card1 or card2), then terminate the access chain and return null.

Working with Nullable Types

Use the following Try It Out to experiment with a nullable Vector type.

List<T>

Rather than derive a class from CollectionBase and implement the required methods as you did in the last chapter, it can be quicker and easier simply to use the List<T> generic collection type. An added bonus here is that many of the methods you normally have to implement, such as Add(), are implemented for you.

Creating a collection of type T objects requires the following code:

List<T> myCollection = new List<T>();

That's it. You don't have to define any classes, implement any methods, or do anything else. You can also set a starting list of items in the collection by passing a List<T> object to the constructor. List<T> also has an Item property, enabling array-like access:

T itemAtIndex2 = myCollectionOfT[2];

This class supports several other methods, but that's plenty to get you started. The following Try It Out demonstrates how to use List<T> in practice.

Sorting and Searching Generic Lists

Sorting a generic list is much the same as sorting any other list. The last chapter described how you can use the IComparer and IComparable interfaces to compare two objects and thereby sort a list of that type of object. The only difference here is that you can use the generic interfaces IComparer<T> and IComparable<T>, which expose slightly different, type-specific methods. Table 12.2 explains these differences.

To sort a List<T>, you can supply an IComparable<T> interface on the type to be sorted, or supply an IComparer<T> interface. Alternatively, you can supply a generic delegate as a sorting method. From the perspective of seeing how the code works, this is far more interesting because implementing the interfaces described here takes no more effort than implementing their nongeneric cousins.

In general terms, all you need to sort a list is a method that compares two objects of type T; and to search, all you need is a method that checks an object of type T to determine whether it meets certain criteria. It is a simple matter to define such methods, and to aid you there are two generic delegate types that you can use:

• Comparison<T> — A delegate type for a method used for sorting, with the following return type and parameters:

  int method(T objectA, T objectB)

• Predicate<T> — A delegate type for a method used for searching, with the following return type and parameters:

  bool method(T targetObject)

You can define any number of such methods, and use them to “snap-in” to the searching and sorting methods of List<T>. The next Try It Out illustrates this technique.

Dictionary<K, V>

The Dictionary<K, V> type enables you to define a collection of key-value pairs. Unlike the other generic collection types you've looked at in this chapter, this class requires instantiating two types: the types for both the key and the value that represent each item in the collection.

Once a Dictionary<K, V> object is instantiated, you can perform much the same operations on it as you can on a class that inherits from DictionaryBase, but with type-safe methods and properties already in place. You can, for example, add key-value pairs using a strongly typed Add() method:

Dictionary<string, int> things = new Dictionary<string, int>();
things.Add("Green Things", 29);
things.Add("Blue Things", 94);
things.Add("Yellow Things", 34);
things.Add("Red Things", 52);
things.Add("Brown Things", 27);

You can iterate through keys and values in the collection by using the Keys and Values properties:

foreach (string key in things.Keys)
{
   WriteLine(key);
}
foreach (int value in things.Values)
{
   WriteLine(value);
}

In addition, you can iterate through items in the collection by obtaining each as a KeyValuePair<K, V> instance, much like you can with the DictionaryEntry objects shown in the last chapter:

foreach (KeyValuePair<string, int> thing in things)
{
   WriteLine($"{thing.Key} = {thing.Value}");
}

One point to note about Dictionary<K, V> is that the key for each item must be unique. Attempting to add an item with an identical key will cause an ArgumentException exception to be thrown. Because of this, Dictionary<K, V> allows you to pass an IComparer<K> interface to its constructor. This might be necessary if you use your own classes as keys and they don't support an IComparable or IComparable<K> interface, or if you want to compare objects using a nondefault process. For instance, in the preceding example, you could use a case-insensitive method to compare string keys:

Dictionary<string, int> things =
   new Dictionary<string, int>(StringComparer.CurrentCultureIgnoreCase);

Now you'll get an exception if you use keys such as this:

things.Add("Green Things", 29);
things.Add("Green things", 94);

You can also pass an initial capacity (with an int) or a set of items (with an IDictionary<K, V> interface) to the constructor.

A feature introduced in C# 6 called index initializers supports the initialization of indices inside the object initializer:

var zahlen = new Dictionary<int, string>()
{
  [1] = "eins",
  [2] = "zwei"
};

Index initializers can be streamlined as in many cases there is no need for a temporary variable as show previously via var zahlen. Using expression-bodied methods, the above example leads to a cascading effect of simplification:

public ZObject ToGerman() => new ZObject() { [1] = "eins", [2] = "zwei"};

Modifying CardLib to Use a Generic Collection Class

One simple modification you can make to the CardLib project you've been building over recent chapters is to change the Cards collection class to use a generic collection class, thus saving many lines of code. The required modification to the class definition for Cards is as follows (you can find this code in Ch12CardLibCards.cs):

   public class Cards : List<Card>, ICloneable { … }

You can also remove all the methods of Cards except Clone(), which is required for ICloneable, and CopyTo(), because the version of CopyTo() supplied by List<Card> works with an array of Card objects, not a Cards collection. Clone() requires a minor modification because the List<T> class does not define a List property to use:

public object Clone()
{
    Cards newCards = new Cards();
    foreach (Card sourceCard in this)
    {
        newCards.Add((Card)sourceCard.Clone());
    }
    return newCards;
}

Rather than show the code here for what is a very simple modification, the updated version of CardLib, called Ch12CardLib, is included in the downloadable code for this chapter, along with the client code from the last chapter.

The default Keyword

One of the most basic things you might want to know about types used to create generic class instances is whether they are reference types or value types. Without knowing this, you can't even assign null values with code such as this:

   public MyGenericClass()
   {
      innerT1Object = null;
   }

If T1 is a value type, then innerT1Object can't have the value null, so this code won't compile. Luckily, this problem has been addressed, resulting in a new use for the default keyword (which you've seen being used in switch structures earlier in the book). This is used as follows:

   public MyGenericClass()
   {
      innerT1Object = default(T1);
   }

The result of this is that innerT1Object is assigned a value of null if it is a reference type, or a default value if it is a value type. This default value is 0 for numeric types, while structs have each of their members initialized to 0 or null in the same way. The default keyword gets you a bit further in terms of doing a little more with the types you are forced to use, but to truly get ahead, you need to constrain the types that are supplied.

Constraining Types

The types you have used with generic classes until now are known as unbounded types because no restrictions are placed on what they can be. By constraining types, it is possible to restrict the types that can be used to instantiate a generic class. There are a number of ways to do this. For example, it's possible to restrict a type to one that inherits from a certain type. Referring back to the Animal, Cow, and Chicken classes used earlier, you could restrict a type to one that was or inherited from Animal, so this code would be fine:

MyGenericClass<Cow> = new MyGenericClass<Cow>();

The following, however, would fail to compile:

MyGenericClass<string> = new MyGenericClass<string>();

In your class definitions this is achieved using the where keyword:

class MyGenericClass<T> where T : constraint { … }

Here, constraint defines what the constraint is. You can supply a number of constraints in this way by separating them with commas:

class MyGenericClass<T> where T : constraint1, constraint2 { … }

You can define constraints on any or all of the types required by the generic class by using multiple where statements:

class MyGenericClass<T1, T2> where T1 : constraint1 where T2 : constraint2
{ … }

Any constraints that you use must appear after the inheritance specifiers:

class MyGenericClass<T1, T2> : MyBaseClass, IMyInterface
   where T1 : constraint1 where T2 : constraint2 { … }

The available constraints are shown in Table 12.3.

It is possible to use one type parameter as a constraint on another through the base-class constraint as follows:

class MyGenericClass<T1, T2> where T2 : T1 { … }

Here, T2 must be the same type as T1 or inherit from T1. This is known as a naked type constraint, meaning that one generic type parameter is used as a constraint on another.

Circular type constraints, as shown here, are forbidden:

class MyGenericClass<T1, T2> where T2 : T1 where T1 : T2 { … }

This code will not compile. In the following Try It Out, you'll define and use a generic class that uses the Animal family of classes shown in earlier chapters.

Inheriting from Generic Classes

The Farm<T> class in the preceding example, as well as several other classes you've seen in this chapter, inherit from a generic type. In the case of Farm<T>, this type was an interface: IEnumerable<T>. Here, the constraint on T supplied by Farm<T> resulted in an additional constraint on T used in IEnumerable<T>. This can be a useful technique for constraining otherwise unbounded types. However, you do need to follow some rules.

First, you can't “unconstrain” types that are constrained in a type from which you are inheriting. In other words, a type T that is used in a type you are inheriting from must be constrained at least as much as it is in that type. For example, the following code is fine:

class SuperFarm<T> : Farm<T>
      where T : SuperCow {}

This works because T is constrained to Animal in Farm<T>, and constraining it to SuperCow is constraining T to a subset of these values. However, the following won't compile:

class SuperFarm<T> : Farm<T>
      where T : struct{}

Here, you can say definitively that the type T supplied to SuperFarm<T> cannot be converted into a T usable by Farm<T>, so the code won't compile.

Even situations in which the constraint is a superset have the same problem:

class SuperFarm<T> : Farm<T>
      where T : class{}

Even though types such as Animal would be allowed by SuperFarm<T>, other types that satisfy the class constraint won't be allowed in Farm<T>. Again, compilation will fail. This rule applies to all the constraint types shown earlier in this chapter.

Also note that if you inherit from a generic type, then you must supply all the required type information, either in the form of other generic type parameters, as shown, or explicitly. This also applies to nongeneric classes that inherit from generic types, as you've seen elsewhere. Here's an example:

public class Cards : List<Card>, ICloneable{}

This is fine, but attempting the following will fail:

public class Cards : List<T>, ICloneable{}

Here, no information is supplied for T, so no compilation is possible.

Generic Operators

Operator overrides are implemented in C# just like other methods and can be implemented in generic classes. For example, you could define the following implicit conversion operator in Farm<T>:

public static implicit operator List<Animal>(Farm<T> farm)
{
   List<Animal> result = new List<Animal>();
   foreach (T animal in farm)
   {
      result.Add(animal);
   }
   return result;
}

This allows the Animal objects in a Farm<T> to be accessed directly as a List<Animal> should you require it. This comes in handy if you want to add two Farm<T> instances together, such as with the following operators:

public static Farm<T> operator +(Farm<T> farm1, List<T> farm2)
{
   Farm<T> result = new Farm<T>();
   foreach (T animal in farm1)
   {
      result.Animals.Add(animal);
   }
   foreach (T animal in farm2)
   {
      if (!result.Animals.Contains(animal))
      {
         result.Animals.Add(animal);
      }
   }
   return result;
}
public static Farm<T> operator +(List<T> farm1, Farm<T> farm2)
         => farm2 + farm1;

You could then add instances of Farm<Animal> and Farm<Cow> as follows:

Farm<Animal> newFarm = farm + dairyFarm;

In this code, dairyFarm (an instance of Farm<Cow>) is implicitly converted into List<Animal>, which is usable by the overloaded + operator in Farm<T>.

You might think that this could be achieved simply by using the following:

public static Farm<T> operator +(Farm<T> farm1, Farm<T> farm2){ … }

However, because Farm<Cow> cannot be converted into Farm<Animal>, the summation will fail. To take this a step further, you could solve this using the following conversion operator:

public static implicit operator Farm<Animal>(Farm<T> farm)
{
   Farm <Animal> result = new Farm <Animal>();
   foreach (T animal in farm)
   {
      result.Animals.Add(animal);
   }
   return result;
}

With this operator, instances of Farm<T>, such as Farm<Cow>, can be converted into instances of Farm<Animal>, solving the problem. You can use either of the methods shown, although the latter is preferable for its simplicity.

Generic Structs

You learned in earlier chapters that structs are essentially the same as classes, barring some minor differences and the fact that a struct is a value type, not a reference type. Because this is the case, generic structs can be created in the same way as generic classes, as shown here:

public struct MyStruct<T1, T2>
{
   public T1 item1;
   public T2 item2;
}