At face value, setting a field to null means that the referenced object is now unrooted from the class that owns the field and, if that was the last root of that reference, the Garbage Collector (GC) is now free to release the memory used by the object that was referenced by that field. Although advanced, this seems all very academic because the amount of time between unrooting the reference and the return from Dispose (and thus the unrooting of the parent object) would seem like a very short amount of time. Even if the amount of time between these two actions is small, setting a single field to null (i.e. a single assignment) seems like such a minor bit of code to provide no adverse affects. The prevalent opinion seems to be that the GC “handles” this case and does what is best for you without setting the field to null.

In fact, this “short amount of time” can be so short as to be negative! A class that nothing else refers to is unrooted as soon as it no longer refers to itself, so objects in .NET can be collected while their instance methods are still executing. I first learned about this from Chris Brumme’s blog. Here is an example that shows this behaviour:

The output is:

start method
collected
end method

Once the method Go() has no references to this, it is eligible for collection. (What this means is that setting fields to null will actually extend the lifetime of the parent object ever-so-slightly.)

However, the code that a using is transformed into will hold onto a reference to the object while its Dispose() method is called, so you won’t get the same behaviour with the following code:

The output is:

start method
end method
collected

This is because the using statement is transformed to something like this:

I think (but cannot confirm) that the reference being held is that of Slow in the outer scope. We can restore the previous behaviour if the using transform was written as this instead:

Either way, I wouldn’t bother setting fields to null in the Dispose() method. (For one thing, these fields can no longer be declared readonly.) And most of the time, the GC is smarter than you are.

	object it = new SomeStruct { Item = 1 };
 
	Floatsy(it);
 
	Console.WriteLine(((SomeStruct)it).Item);

At runtime, it will throw an InvalidCastException!

Here’s how. In .NET, each object has also associated with it a value which determines the type of the object. In memory, this is stored before the object’s data, like so (I got this information from the MSDN article Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects):

Now, if we can write to that, we can set the type of the object to whatever we want!

There’s one small problem — in .NET we can’t take the address of a managed object (which we need in order to write to the object in memory). There are various reasons for this, one of them being that the garbage collector likes to be able to move objects around. Being able to take arbitrary pointers of objects would mean that the pointers could become invalidated.

What we can do is to pin a struct, which allows us to retrieve the address of it (this facility exists so that users can pass pinned managed structs into unmanaged code as pointers). Here’s how to pin a struct:

    var handle = GCHandle.Alloc(o, GCHandleType.Pinned);
    var addr = handle.AddrOfPinnedObject();

We can then write to the type handle like so (both the sync block and type handle are 32 bits):

    *(((int*)addr)-1) = someValue;

Another problem is that all of this is only true for values on the heap. As far as I can tell, the static type of the variable is what .NET uses to identify values on the stack. So in order for this to work, we must use a boxed copy of a struct.

Finally, here’s some demo code, showing runtime changing of types for both a primitive and custom struct:

using System;
using System.Runtime.InteropServices;
 
unsafe class Program
{
    struct SomeStruct { public int Item; }
 
    public static void Main()
    {
        object notAFloat = 1;
        object me = new SomeStruct {Item = 1};
 
        Console.WriteLine("{0} ({1})", notAFloat, notAFloat.GetType());
        Floatify(notAFloat);
        Console.WriteLine("{0} ({1})", notAFloat, notAFloat.GetType());
        Console.WriteLine();
        Console.WriteLine(me);
        Floatify(me);
        Console.WriteLine(me);
    }
 
    static void Floatify<T>(T o)
    {
        var handle = GCHandle.Alloc(o, GCHandleType.Pinned);
        var addr = handle.AddrOfPinnedObject();
 
        object f = (float)1.0;
        var handle2 = GCHandle.Alloc(f, GCHandleType.Pinned);
        var addr2 = handle2.AddrOfPinnedObject();
 
        // copy type handle of a float to the object
        *(((int*)addr)-1) = *(((int*)addr2)-1);
 
        handle2.Free();
        handle.Free();
    }
}

The output is:

1 (System.Int32)
1.401298E-45 (System.Single)

Program+SomeStruct
1.401298E-45

public IEnumerator<T> GetEnumerator()
{
    return new Stream<T,Node>(first,
        node => node.next == null ? null : Tuple.Of(node.next, node.datum).AsNullable());
}

This uses the following utility class to implement the enumerator in one line (along with some code for Tuples and an extension method for structs):

public class Stream<Tdata, Tstate> : IEnumerator<Tdata>
{
    private Tdata current;
    private Tstate initialState;
    private Tstate state;
    private Func<Tstate, Pair<Tstate, Tdata>?> moveNext;
 
    public Stream(Tstate initialState, Func<Tstate, Pair<Tstate, Tdata>?> calcNextValue)
    {
        moveNext = calcNextValue;
        this.initialState = initialState;
        Reset();
    }
 
    #region IEnumerator<Tdata> Members
 
    public Tdata Current
    {
        get { return current; }
    }
 
    #endregion
 
    #region IDisposable Members
 
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }
 
    protected void Dispose(bool disposing)
    {
        if (disposing)
        {
            var disposeCurrent = current as IDisposable;
            if (disposeCurrent != null)
                disposeCurrent.Dispose();
 
            var disposeState = state as IDisposable;
            if (disposeState != null)
            {
                disposeState.Dispose();
                //safe; have checked already above.
                //type of state == type of initialstate
                ((IDisposable)initialState).Dispose();
            }
        }
    }
 
    #endregion
 
    #region IEnumerator Members
 
    object System.Collections.IEnumerator.Current
    {
        get { return current; }
    }
 
    public bool MoveNext()
    {
        var result = moveNext(state);
 
        if (result.HasValue)
        {
            current = result.Value.Right;
            state = result.Value.Left;
            return true;
        }
        else
            return false;
    }
 
    public void Reset()
    {
        state = initialState;
    }
 
    #endregion
}

public static bool Equals(object objA, object objB)
{
    return ((objA == objB) || (((objA != null) && (objB != null)) && objA.Equals(objB)));
}

It seems that not even Microsoft knows this! I spotted this code, from ASP.NET’s MVC implementation, on Scott Hanselman’s blog:

return (other != null) &&
  (((other._first == null) && (_first == null)) ||
    ((other._first != null) && other._first.Equals(_first))) &&
  (((other._second == null) && (_second == null)) ||
    ((other._second != null) && other._second.Equals(_second)));

This can be rewritten as:

return (other != null) &&
  object.Equals(other._first, _first) &&
  object.Equals(other._second, _second);

Much nicer!

Due to minor demand, the code is also available: BigNum source.

Please note that I haven’t actually touched the code since it was first written. I’m sure there’s some things that don’t work properly. If you’re doing anything big with this you probably want to write some ‘destructive’ update functions for adding, etc. At the moment every time you add, subtract, etc, a completely new BigInt is returned. To make it faster you’d want to just update the number in-place.

Original content…

I’ve created a simple wrapper for GMP. At the moment only BigInts are implemented, but I expect to have BigRationals and BigFloats coming along soon enough. (Edit: this never happened.)

Usage

I think this is very close to as-you’d-expect. The only minor thing that might come as a surprise is that BigInts aren’t value types; since they need destructors, they can’t be. The rest is fairly straightforward:

static void Main(string[] args) {
    BigInt n;
    for (ulong i = 100; i <= 999; i++) {
        n = BigInt.Factorial(i);
        Console.WriteLine(n);
    }
    Console.ReadLine();
}

This code executes with sub 5-second times, which I’m pretty pleased with. I’m not sure what kind of performance decrease you get through using GMP under managed code.

Caveats

• Consider this alpha software
• The included GMP DLL is compiled with none of the magical assembly they provide. If you want to, you can compile it yourself with all this enabled, and you should be able to just use it as a drop-in replacement.

Download

Available here: BigNum library. Documentation is available.