Checking instance of non-class constrained type pa

Question

I currently have a generic method where I want to do some validation on the parameters before working on them. Specifically, if the instance of the type parameter T is a reference type, I want to check to see if it's null and throw an ArgumentNullException if it's null.

Something along the lines of:

// This can be a method on a generic class, it does not matter.
public void DoSomething<T>(T instance)
{
    if (instance == null) throw new ArgumentNullException("instance");

Note, I do not wish to constrain my type parameter using the class constraint.

I thought I could use Marc Gravell's answer on "How do I compare a generic type to its default value?", and use the EqualityComparer<T> class like so:

static void DoSomething<T>(T instance)
{
    if (EqualityComparer<T>.Default.Equals(instance, null))
        throw new ArgumentNullException("instance");

But it gives a very ambiguous error on the call to Equals:

Member 'object.Equals(object, object)' cannot be accessed with an instance reference; qualify it with a type name instead

How can I check an instance of T against null when T is not constrained on being a value or reference type?

Answer 1

There's a few ways to do this. Often, in the framework (if you look at source code through Reflector), you'll see a cast of the instance of the type parameter to object and then checking that against null, like so:

if (((object) instance) == null)
    throw new ArgumentNullException("instance");

And for the most part, this is fine. However, there's a problem.

Consider the five main cases where an unconstrained instance of T could be checked against null:

• An instance of a value type that is not Nullable<T>
• An instance of a value type that is Nullable<T> but is not null
• An instance of a value type that is Nullable<T> but is null
• An instance of a reference type that is not null
• An instance of a reference type that is null

In most of these cases, the performance is fine, but in the cases where you are comparing against Nullable<T>, there's a severe performance hit, more than an order of magnitude in one case and at least five times as much in the other case.

First, let's define the method:

static bool IsNullCast<T>(T instance)
{
    return ((object) instance == null);
}

As well as the test harness method:

private const int Iterations = 100000000;

static void Test(Action a)
{
    // Start the stopwatch.
    Stopwatch s = Stopwatch.StartNew();

    // Loop
    for (int i = 0; i < Iterations; ++i)
    {
        // Perform the action.
        a();
    }

    // Write the time.
    Console.WriteLine("Time: {0} ms", s.ElapsedMilliseconds);

    // Collect garbage to not interfere with other tests.
    GC.Collect();
}

Something should be said about the fact that it takes ten million iterations to point this out.

There's definitely an argument that it doesn't matter, and normally, I'd agree. However, I found this over the course of iterating over a very large set of data in a tight loop (building decision trees for tens of thousands of items with hundreds of attributes each) and it was a definite factor.

That said, here are the tests against the casting method:

Console.WriteLine("Value type");
Test(() => IsNullCast(1));
Console.WriteLine();

Console.WriteLine("Non-null nullable value type");
Test(() => IsNullCast((int?)1));
Console.WriteLine();

Console.WriteLine("Null nullable value type");
Test(() => IsNullCast((int?)null));
Console.WriteLine();

// The object.
var o = new object();

Console.WriteLine("Not null reference type.");
Test(() => IsNullCast(o));
Console.WriteLine();

// Set to null.
o = null;

Console.WriteLine("Not null reference type.");
Test(() => IsNullCast<object>(null));
Console.WriteLine();

This outputs:

Value type
Time: 1171 ms

Non-null nullable value type
Time: 18779 ms

Null nullable value type
Time: 9757 ms

Not null reference type.
Time: 812 ms

Null reference type.
Time: 849 ms

Note in the case of a non-null Nullable<T> as well as a null Nullable<T>; the first is over fifteen times slower than checking against a value type that is not Nullable<T> while the second is at least eight times as slow.

The reason for this is boxing. For every instance of Nullable<T> that is passed in, when casting to object for a comparison, the value type has to be boxed, which means an allocation on the heap, etc.

This can be improved upon, however, by compiling code on the fly. A helper class can be defined which will provide the implementation of a call to IsNull, assigned on the fly when the type is created, like so:

static class IsNullHelper<T>
{
    private static Predicate<T> CreatePredicate()
    {
        // If the default is not null, then
        // set to false.
        if (((object) default(T)) != null) return t => false;

        // Create the expression that checks and return.
        ParameterExpression p = Expression.Parameter(typeof (T), "t");

        // Compare to null.
        BinaryExpression equals = Expression.Equal(p, 
            Expression.Constant(null, typeof(T)));

        // Create the lambda and return.
        return Expression.Lambda<Predicate<T>>(equals, p).Compile();
    }

    internal static readonly Predicate<T> IsNull = CreatePredicate();
}

A few things to note:

• We're actually using the same trick of casting the instance of the result of default(T) to object in order to see if the type can have null assigned to it. It's ok to do here, because it's only being called once per type that this is being called for.
• If the default value for T is not null, then it's assumed null cannot be assigned to an instance of T. In this case, there's no reason to actually generate a lambda using the Expression class, as the condition is always false.
• If the type can have null assigned to it, then it's easy enough to create a lambda expression which compares against null and then compile it on-the-fly.

Now, running this test:

Console.WriteLine("Value type");
Test(() => IsNullHelper<int>.IsNull(1));
Console.WriteLine();

Console.WriteLine("Non-null nullable value type");
Test(() => IsNullHelper<int?>.IsNull(1));
Console.WriteLine();

Console.WriteLine("Null nullable value type");
Test(() => IsNullHelper<int?>.IsNull(null));
Console.WriteLine();

// The object.
var o = new object();

Console.WriteLine("Not null reference type.");
Test(() => IsNullHelper<object>.IsNull(o));
Console.WriteLine();

Console.WriteLine("Null reference type.");
Test(() => IsNullHelper<object>.IsNull(null));
Console.WriteLine();

The output is:

Value type
Time: 959 ms

Non-null nullable value type
Time: 1365 ms

Null nullable value type
Time: 788 ms

Not null reference type.
Time: 604 ms

Null reference type.
Time: 646 ms

These numbers are much better in the two cases above, and overall better (although negligible) in the others. There's no boxing, and the Nullable<T> is copied onto the stack, which is a much faster operation than creating a new object on the heap (which the prior test was doing).

One could go further and use Reflection Emit to generate an interface implementation on the fly, but I've found the results to be negligible, if not worse than using a compiled lambda. The code is also more difficult to maintain, as you have to create new builders for the type, as well as possibly an assembly and module.