Trying to understand static constructors

Question

I am trying to understand need for static constructors. None of information I found answered following question I have. Why would you do this

class SimpleClass
{
    // Static variable that must be initialized at run time.
    static readonly long baseline;

    // Static constructor is called at most one time, before any
    // instance constructor is invoked or member is accessed.
    static SimpleClass()
    {
        baseline = DateTime.Now.Ticks;
    }
}

as opposed to this

class SimpleClass
{
    // Static variable that must be initialized at run time.
    static readonly long baseline = DateTime.Now.Ticks;

    // Static constructor is called at most one time, before any
    // instance constructor is invoked or member is accessed.
    //static SimpleClass()
    //{

    //}
}

?

---

This is not dupe of other question, this is about static constructors which don't accept parameters.

Answer 1

The need is somehow obvious: You want to do more than some field initialization for your static members.

Logically if you have this class:

class SimpleClass
{
    // Static variable that must be initialized at run time.
    static readonly long baseline = DateTime.Now.Ticks;


}

You can re-write it to have the same effect:

class SimpleClass
{
    // Static variable that must be initialized at run time.
    static readonly long baseline;

    static SimpleClass () {
        baseline = DateTime.Now.Ticks;
    }   
}

But instead, you could do more in your static constructor such as inspecting (using reflection) some properties and emiting some fast accessors / getters to them, or just simple notify other systems that your type has been created, etc.

From Jeffrey Richter CLR via C# book:

When the C# compiler sees a class with static fields that use inline initialization (the BeforeFieldInit class), the compiler emits the class’s type definition table entry with the BeforeFieldInit metadata flag. When the C# compiler sees a class with an explicit type constructor (the Precise class), the compiler emits the class’s type definition table entry without the BeforeFieldInit metadata flag. The rationale behind this is as follows: initialization of static fields needs to be done before the fields are accessed, whereas an explicit type constructor can contain arbitrary code that can have observable side effects; this code may need to run at a precise time.

Obviouselly there is something more than this happening behind the scenes, I would suggest you to read entire chapter from CLR via C#: "Type Constructors"

Answer 2

This is an example of a possible difference:

class SimpleClass
{
    static readonly long A = DateTime.Now.Ticks;
    static readonly long B = DateTime.Now.Ticks;

    static SimpleClass()
    {
    }
}

A and B are not guaranteed to be the same value, though if you were to write it in the constructor, you could guarantee it:

class SimpleClass
{
    static readonly long A;
    static readonly long B;

    static SimpleClass()
    {
        var ticks = DateTime.Now.Ticks;
        A = ticks;
        B = ticks;
    }
}

In addition, order matters for instantiation of static members.

According to ECMA-334 regarding static field initialization:

The static field variable initializers of a class declaration correspond to a sequence of assignments that are executed in the textual order in which they appear in the class declaration. If a static constructor (§17.11) exists in the class, execution of the static field initializers occurs immediately prior to executing that static constructor. Otherwise, the static field initializers are executed at an implementation-dependent time prior to the first use of a static field of that class

So, we can write something like this:

class SimpleClass
{
   public static readonly long A = IdentityHelper.GetNext();
   public static readonly long B = IdentityHelper.GetNext();

   static SimpleClass()
   {
   }
}

public static class IdentityHelper
{
    public static int previousIdentity = 0;
    public static int GetNext()
    {
        return ++previousIdentity;
    }
}

Here, A is guaranteed to be assigned before B. In this example, A will be 1, and B will be 2. We can guarantee that A < B (assuming the identity does not overflow and there's no issues with threading). Now, if we re-order the fields:

public static readonly long B = IdentityHelper.GetNext();
public static readonly long A = IdentityHelper.GetNext();

The functionality changes. Thus, we've created a side-effect which is not immediately clear simply by re-ordering the fields definitions.

A more likely scenario is, we may want to do this:

class SimpleClass
{
   public static readonly long A = IdentityHelper.GetExpensiveResult().A;
   public static readonly long B = IdentityHelper.GetExpensiveResult().B;

   static SimpleClass()
   {
   }
}

Here, we're unable to share GetExpensiveResult() between the fields.