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

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

Rate This
  • Comments 36

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!

 

  • 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");

           }

  • 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.

  • 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.

  • 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."

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

  • 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"))

  • C# Code behind is fabulous. Thanks.

    JFront

  • 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.

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

  • 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...

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

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

  • 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.

  • 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!

  • 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!

Page 2 of 3 (36 items) 123