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

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

Jon Skeet — Sat, 16 Feb 2008 11:05:55 GMT

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

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

Barry Kelly — Sat, 16 Feb 2008 12:58:26 GMT

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.

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

Alex Simkin — Sat, 16 Feb 2008 20:49:37 GMT

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

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

Eric Lippert — Sat, 16 Feb 2008 21:54:38 GMT

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.

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

David Moles — Mon, 18 Feb 2008 15:51:25 GMT

1. Accurate.

2. Misleading. [Waves to James Gosling.]

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

Alex Simkin — Mon, 18 Feb 2008 17:54:47 GMT

Just a note. VB.NET does initialization differently.

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

Franck Jeannin — Mon, 18 Feb 2008 18:02:44 GMT

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();

}

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

Richard — Mon, 18 Feb 2008 19:19:14 GMT

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

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

Eric Lippert — Mon, 18 Feb 2008 21:20:22 GMT

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.

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

Ian Marteens — Tue, 19 Feb 2008 01:11:36 GMT

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.

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

arepetti — Tue, 19 Feb 2008 16:04:44 GMT

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

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

Luke — Thu, 21 Feb 2008 16:20:34 GMT

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

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

Kyralessa — Fri, 29 Feb 2008 02:35:44 GMT

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.

Community Convergence XLI

Charlie Calvert's Community Blog — Wed, 12 Mar 2008 00:35:40 GMT

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

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

Ben Voigt — Wed, 12 Mar 2008 22:37:20 GMT

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

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

Jim — Tue, 25 Mar 2008 19:57:05 GMT

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

}

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

Cerror — Thu, 27 Mar 2008 16:50:09 GMT

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.

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

arkain — Mon, 31 Mar 2008 02:17:48 GMT

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.

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

kshetgar — Mon, 31 Mar 2008 17:36:03 GMT

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

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

Dogu Tumerdem — Wed, 02 Apr 2008 10:21:55 GMT

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

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

Don Dillard — Fri, 04 Apr 2008 17:59:44 GMT

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

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

JFront — Sun, 18 May 2008 07:38:16 GMT

C# Code behind is fabulous. Thanks.

JFront

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

PK — Wed, 21 May 2008 15:49:24 GMT

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.

Order of Construction

Jason Crease — Mon, 02 Jun 2008 18:07:36 GMT

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

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

latek — Tue, 03 Jun 2008 23:26:02 GMT

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

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

Thu, 05 Jun 2008 06:02:28 GMT

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

C# 小测试（一）：类成员实例化与构造函数执行的顺序

Anders Cui — Sat, 12 Jul 2008 15:27:47 GMT

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

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

Bill Sanders — Tue, 05 Aug 2008 03:03:21 GMT

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.

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

Atreya A — Sun, 31 Aug 2008 21:14:40 GMT

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!

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

Atreya A — Sun, 31 Aug 2008 21:19:56 GMT

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!

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

Biggles — Thu, 02 Oct 2008 05:50:39 GMT

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

worry about it.

Mutating Readonly Structs

Fabulous Adventures In Coding — Mon, 19 Jan 2009 03:03:50 GMT

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

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

Java Guy — Fri, 08 May 2009 18:54:39 GMT

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

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

lance7 — Sun, 28 Jun 2009 01:08:47 GMT

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