Why Do Initializers Run In The Opposite Order As Constructors? Part One


Pop quiz!

What do you expect the output of this program to be?

 

using System;

class Foo
{
    public Foo(string s)
    {
        Console.WriteLine(“Foo constructor: {0}”, s);
    }
    public void Bar() { }
}
class Base
{
    readonly Foo baseFoo = new Foo(“Base initializer”);
    public Base()
    {
        Console.WriteLine(“Base constructor”);
    }
}
class Derived : Base
{
    readonly Foo derivedFoo = new Foo(“Derived initializer”);
    public Derived()
    {
        Console.WriteLine(“Derived constructor”);
    }
}
static class Program
{
    static void Main()
    {
        new Derived();
    }
}

I got a question from a user recently noting that the order was not as he expected. One naively expects that the order will go “base initializers, base constructor body, derived initializers, derived constructor body”. In fact the order actually is that first all the initializers run in order from derived to base, and then all the constructor bodies run in order from base to derived.

The latter bit makes perfect sense; the more derived constructors may rely upon state initialized by the less derived constructors, so the constructors should run in order from base to derived. But most people assume that the call sequence of the code above is equivalent to this pseudocode:

// Expected
BaseConstructor()
{
    ObjectConstructor();
    baseFoo = new Foo(“Base initializer”);
    Console.WriteLine(“Base constructor”);
}
DerivedConstructor()
{
    BaseConstructor();
    derivedFoo = new Foo(“Derived initializer”);
    Console.WriteLine(“Derived constructor”);
}

When in point of fact it is equivalent to this:

 // Actual
BaseConstructor()
{
    baseFoo = new Foo(“Base initializer”);
    ObjectConstructor();
    Console.WriteLine(“Base constructor”);
}
DerivedConstructor()
{
     derivedFoo = new Foo(“Derived initializer”);
    BaseConstructor();
    Console.WriteLine(“Derived constructor”);
}

That explains the mechanism whereby the initializers run in order from derived to base and the constructor bodies run in the opposite order, but why did we choose to implement that mechanism instead of the more intuitively obvious former way?

Puzzle that one over for a bit, and then read on for a hint.

The “readonly” modifiers in there were no accident. The code gives the appearance that any call to derivedFoo.Bar() and baseFoo.Bar() should never fail with a null dereference exception because both are readonly fields initialized to non-null values.

  1. Is that appearance accurate, or misleading?
  2. Now suppose initializers ran in the “expected” order and answer question (1) again. 

I’ll post the answers and analysis next week. Have a fabulous weekend!

 

Comments (36)

  1. Jon Skeet says:

    Possible spoilers by implication, so ROT-13.

    V’ir nyjnlf yvxrq vg gur jnl vg vf – orpnhfr V’ir rkcrevraprq gur cnva bs vg orvat gur bgure jnl ebhaq.

    Gur rdhvinyrag (va grezf bs fbhepr) Wnin cebtenz jevgrf:

    Sbb pbafgehpgbe: Onfr vavgvnyvmre

    Onfr pbafgehpgbe

    Sbb pbafgehpgbe: Qrevirq vavgvnyvmre

    Qrevirq pbafgehpgbe

    Guvf orunivbhe pnhfrq n irel uneq-gb-qvntabfr reebe va n pbyyrnthr’f pbqr znal zbbaf ntb. Vg graqf abg gb znggre vs lbh qba’g znxr iveghny pnyyf jvguva gur onfr pbafgehpgbe, ohg gung’f rknpgyl jung gur zbfg angheny qrfvta pnyyrq sbe va guvf pnfr. (Gung jnf jura V svefg yrnearq gung vg’f n onq vqrn gb znxr iveghny pnyyf sebz n pbafgehpgbe!)

  2. Barry Kelly says:

    The most obvious thing that comes to my mind is virtual method calls in ancestor constructors. Bad practice in any case, though sometimes it’s the most natural solution.

  3. Alex Simkin says:

    Actually implementation is rather confusing.

    Make baseFoo and derivedFoo fields static and run the application. Derived will be initialized before base as with non-static fields.

    Then, modify constructor of Foo to take reference to Foo and pass baseFoo to derivedFoo constructor. The initialization sequence will change to Base first, then Derived.

    Confusing…

  4. EricLippert says:

    Ah, yes. I should have mentioned that. The rules for static constructors and static fields are subtly different, and I do not intend this article to discuss anything about the rules for statics. That’s a great topic for a follow-up article.

  5. David Moles says:

    1. Accurate.

    2. Misleading. [Waves to James Gosling.]

  6. Alex Simkin says:

    Just a note. VB.NET does initialization differently.

  7. Franck Jeannin says:

    I suspect there is a good reason behind every ‘confusing’ behavior… I think I know why the following program has to behave that way but I find it confusing nevertheless.

    class Program {

           static void Main() {

               B b = new B();

               b.Display();

               b.OtherDisplay();

           }

       }

       class A {

            public void Display() {

               Console.WriteLine("from A");

           }

       }

       class B : A {

           new void Display() {

               Console.WriteLine("from B");

           }

           public void OtherDisplay() {

               Display();

           }

       }

  8. Richard says:

    I’ll make a guess:

    If it’s done the ‘obvious’ way, there exists a point (during the base constructor) where the derived readonly field exists but is 0. There exists a later point where the same (readonly) field has a different value. That’s presumably not good.

    If it’s done the other way around, then by the time any code runs which has access to the new object (the ObjectConstructor), all the readonly fields are fully initialized.

    I’ll guess further that this behaviour is due to some kind of weirdness in C# whereby the object’s dynamic type is the type of the full object throughout construction, rather than the dynamic type changing as more constructors get called, as happens in C++.

  9. EricLippert says:

    Correct, though your characterization of the CLR semantics for the dynamic type of an object as "weirdness" is itself somewhat weird. I would argue that it is more weird for the dynamic type of an object to change throughout that object’s lifetime!  The type of an object is a constant from the moment it is created through to the moment it is destroyed. Mutable objects are hard enough to reason about; objects that mutate their own runtime type are truly odd.

  10. Ian Marteens says:

    A useful addition to C# would be to allow field initializers in true C++ fashion:

    public class Stack<T>

    {

       private T[] items;

       private int count;

       public Stack<T>(int capacity) : items(new T[capacity]) { }

       // …

    }

    This corresponding IL code is currently tolerated by the CLR, and it solves several problems with assertions regarding nullability of fields.

  11. arepetti says:

    class Base

    {

    readonly int baseFooValue = 1;

    public Base()

    {

      Console.WriteLine(Foo().ToString());

    }

    protected virtual int Foo()

    {

     return baseFooValue ;

    }

    }

    class Derived : Base

    {

    readonly derivedFooValue = 2;

    public Derived()

    {

    }

    protected override int Foo()

    {

     return derivedFooValue ;

    }

    }

    This will print "2" but with the expected behavior it would print "0"!

  12. Luke says:

    Removing readonly modifier does not make any difference in the result. Am I missing something?

  13. Kyralessa says:

    It’s interesting to note that in VB .NET this isn’t confusing at all.  The syntax makes it clear what happens.  If you explicitly call the base constructor, and you do it like this…

    Public Sub New()

       ‘ some other code, and then:

       MyBase.New()

    End Sub

    …the compiler tells you the base constructor call has to be the first line.  Which makes it obvious, since it looks like a method call, that the base constructor’s body gets executed first.

    The C# syntax, unfortunately, is a bit more obtuse to those not familiar with it.

  14. Welcome to the forty-first Community Convergence. The big news this week is that we have moved Future

  15. Ben Voigt says:

    Wouldn’t the following order make the most sense (since base initializers have no way of referring to derived variables, but the reverse isn’t true)?  Or can you provide a counter-example?

    base initializer

    derived initializer

    base constructor

    derived constructor

  16. Jim says:

    I think your point is: If the the initialization is not done first, then if the Derived class tried to reference the base.baseFoo.Bar() function in it’s constructor baseFoo may be a null reference, correct?

    public Derived()

           {

               base.baseFoo.Bar();

               Console.WriteLine("Derived constructor");

           }

  17. Cerror says:

    When we call Derived() constructor, The Base object should be created first, include all of its field. So of cause we can use the member of Base class in the Derived() constructor. But why should we initialize the Derived’s readonly field before the Base field? I think it just let the compiler developing a little easy.

  18. arkain says:

    This shouldn’t be as confusing as it seems. Consider what the compiler sees when I tries to construct A:

    public Class Base { … }

    public Class Derived1 : Base { … }

    public Class Derived2 : Derived1 { … }

    Derived2 A;

    The compiler only knows that A is of type Derived2. So it has no choice but to depend on Derived2 to have all of the info required to build any ancestor classes. That’s where initializers come in. The constructor for a class always uses its initializer to call the constructor of its base class before it does anything else. This should explain why the initializers are called first and in reverse order.

    When the last initializer calls the lowest base class constructor, there’s no more base classes in the chain, so now it’s time to execute all the constuctors. As each constructor is completed, the stack unwinds and each constructor is executed in turn from the base to the most derived. Hence the forward order of constructor execution.

    For VB fans, consider that your objects don’t have initializers. This means that base class constructors have to be called manually. As such, the only way to ensure that the entire class is properly constructed before executing dangerous constructor content in the derived class is to make sure that the base constructor is called as the very first line of the derived class’s constructor. This makes VB class construction function identically to that in C++ and C#.

    When you think about it, it’s just not possible to call in this order:

    base initializer -> base constructor -> derived initializer -> derived constructor

    Since the initializer’s job is to call the ancestor’s constructor, there’d be nothing for the initializers to do.

  19. kshetgar says:

    I agree with Arkain. It makes sense that "Since the initializer’s job is to call the ancestor’s constructor, there’d be nothing for the initializers to do."

  20. Dogu Tumerdem says:

    readonly modifiers causes a kind of static initialization. that’s why it will be initialized in reverse manner.

  21. Don Dillard says:

    The output order becomes understandable when you look at the derived class

    like it actually works.  Note, I put the call to the base construcctor on

    the Derived constructor.

    class Derived : Base

    {

       Foo derivedFoo = new Foo("Derived initializer");

       public Derived() : base()          <————- where the base is actually called

       {        

           Console.WriteLine("Derived constructor");

       }

    }

    If I change the Base constructor to take a Foo

    parameter, why can’t I pass Derived.derivedFoo?  It’s clearly intialized!

    class Base

    {

       Foo baseFoo = new Foo("Base initializer");

       public Base(Foo f)        <————————-  change

       {

           Console.WriteLine("Base constructor");

           baseFoo = f;

       }

    }

    class Derived : Base

    {

       Foo derivedFoo = new Foo("Derived initializer");

       public Derived() : base(derivedFoo)          <————-  error

       {        

           Console.WriteLine("Derived constructor");

       }

    }

    Note this works:  base(new Foo("bubba"))

  22. JFront says:

    C# Code behind is fabulous. Thanks.

    JFront

  23. PK says:

    Process of creating an Instance of a Class goes in the following order: (static would be different)

    Step 1) Compiler executes code related to instance variable declarations; this is to identify the fields required to construct the instance.

    Step 2) Compiler executes the desired constructor – Constructor is the first method that is called on an instance.

    Trick is here: To construct a Derived class instance a base class instance needs to be constructed.

    Let’s get back to the code we are looking at:

    1) Line ‘new Derived();’ of the ‘static void Main()’ method creates an instance of ‘Derived’ class. So the compiler should run Step 1 on ‘Derived’ class.

    Result: ‘Foo constructor: Derived initializer’ is written to the console.

    2) Compiler should run Step 2 on ‘Derived’ class. To create an instance of the derived class it first needs to construct the base class instance. Hence,

    i) Step 1 is called on ‘Base’ class.

    Result: ‘Foo constructor: Base initializer’ is written to the console.

    ii) After Step 1, Step 2 is called on ‘Base’ class.

    Result: ‘Base constructor’ is written to the console.

    Since the Base class instance is constructed, it finishes with constructing the Derived class by calling Step 2 on the ‘Derived’ class

    Result: ‘Derived constructor’ is written to the console.

    Guess this helps to understand the behavior.

  24. Jason Crease says:

    For me, inheritance is often a headache. In particular, in what order is everything initialized? …

  25. latek says:

    As PK explained,

    Order execution is a recursive process:

    For example:

    BASE CLASS A

    DERIVED CLASS B : A

    DERIVER CLASS C : B

    If we like to make instance of class C, it will go like this

    in this pleudocode will look like this:

    MAKEINSTANCE (C)

    VOID MAKEINSTANCE (type X)

        1. identify and initialise the local fields required to construct the instance X

        2. if X is derived class  then  MAKEINSTANCE (base of X)  //recursive call

        3. call X constructor

    END VOID

    So the execution path will be:

    Fields Initialising C

      //check, C is derived from B

      Fields Initialising B

        //check B is derived from A

        Fields Initialisiing A

        Call constructor A

      Call constructor B

    Call constructor C

    Hope  this hepls someone…

  26. J says:

    Base initializer or Base constructor prior to ObjectConstructor might be helpful to do better for objectconstructor.

  27. Anders Cui says:

    我们在实现类的继承时,创建派生类的实例时,基类与派生类的实例字段都要进行实例化,他们的构造函数都需要调用,那执行的顺序是怎样的呢?一起来做做这个测试题吧。

  28. Bill Sanders says:

    If someone has mentioned this above and I missed it, I apologize for repeating, but one potentially "snagly" situation I can think of is this: constructor of Base calls a method of Base which is overridden in Derived and whose overridden behavior references a (non-static initonly) member of Derived which has not yet been initialized.

  29. Atreya A says:

    Hi All,

    What i feel is that it always that initializers run first; and the pointer to base is also a member of derived class and in order to initialize that member the control passes to base class.

    All i mean to say is that the process of object creation and initialization always starts first at the derived class only. Where as in order to construct or initialize the derived object completely we need instance of base class as well; that is why the partially initialized derived object is pushed to stack for time being and control moves to base class.

    As soon as the base class is completely initialized the partially initialized object is popped from the stack and initialized completely using the base object which is now available.

    So in the meantime when our partially initialized object of derived class is taking some rest in the stack, the initialization of base object completes and we feel that the process has started from the base class only. Whereas this is just an illusion.

    Have a look at the sample code below and then just read the sequence of activities:

    class classBase

    {

       int a = 0;

       int b = 1;

       public void classBase()

       {

          Console.WriteLine("Base Class Constructor called");

       }

    }

    class classDerived : classBase

    {

      int c = 2;

      int d = 3;

       public void classDerived()

       {

          Console.WriteLine("Derived Class Constructor called");

       }

    }

    1.) Initialization of derived class object starts

    2.) All members except the reference to base class are initialized

    3.) When .NET tries to initialize the reference to object base class; it is found to be NULL

    4.) The partially initialized object of derived class is pushed to STACK

    5.) Initialization of Base class starts

    6.) All members are initialized since there is no dependency

    7.) CONSTRUCTOR of base class is called to complete process of object creation of Base class  

    8.) Code in CONSTRUCTOR of base class executes.

    9.) Now control returns to derived class object

    10.) Partially initialized object of derived class is POPPED from the Stack.

    11.) Initialization of Derived class object completes as now we have reference to base class object as well.

    12.) CONSTRUCTOR of derived class is called to complete process of object creation of Derived class  

    13.) Code in CONSTRUCTOR of Derived class executes.

    namaste!

  30. Atreya A says:

    I just noticed that ‘PK’ and me are trying to convey almost one and the same thing.

    Before this i was doubtfull about my post but now i am 100% sure that mine (and PK’s as well) is the right answer for the question asked in this post 🙂

    namaste!

  31. Biggles says:

    This is why i always initialize variables in the constructor. That way u dont have to

    worry about it.

  32. Consider this program which attempts to mutate a readonly mutable struct. What happens? struct Mutable

  33. Java Guy says:

    Exactly as Bill Sanders said. This init order is to support a polymorhic method call in the constructor.

  34. lance7 says:

    it always that initializers run first- this is a key point

  35. Syed Salman Akbar says:

    It is actually very sound to run initializes first from derived to base while constructors from base to derived. The basic purpose of the constructor is to assign some values to the member fields. Right? Now to assign the member fields the runtime must first be able to see what are those member fields? Now just have a look at the initalizer. What is an initializer? Very simply it is a statement assigning a value upon declaration.

    Now when an object is create for a particular class the fields of the class should be first declared correctly. Then it’s base class and then base of that base class until we reach system. Object. This is like constructing a building where engineers create the outer most walls of the structure first which in this case will be the fields of the outer most class. And then the support pillars inside the building. Now think of constructors as creating floors in the building. You create first floor that is the system. Object’s constructor, then you create the first floor (next class after system. object) and then you create the next till you get to last class which is the class whose object is being initialized.

  36. Syed Salman Akbar says:

    It is actually very sound to run initializes first from derived to base while constructors from base to derived. The basic purpose of the constructor is to assign some values to the member fields. Right? Now to assign the member fields the runtime must first be able to see what are those member fields? Now just have a look at the initalizer. What is an initializer? Very simply it is a statement assigning a value upon declaration.

    Now when an object is create for a particular class the fields of the class should be first declared correctly. Then it’s base class and then base of that base class until we reach system. Object. This is like constructing a building where engineers create the outer most walls of the structure first which in this case will be the fields of the outer most class. And then the support pillars inside the building. Now think of constructors as creating floors in the building. You create first floor that is the system. Object’s constructor, then you create the first floor (next class after system. object) and then you create the next till you get to last class which is the class whose object is being initialized.