Initialization order in constructor

[Vedam Shashank]

CMyClass
{
	Some_Type_1 obj1;
	Some_Type_2 obj2;
public:
	CMyClass() : obj2(...), obj1(...){};
};

Standard says: Class members are initialized in the order of declaration. Fine.
But, why is it not advisiable to do the above???

[NMTop40]

It's not advisable to do the above but it might be confusing. It will ignore the order in your initialiser list and initialise obj1 first anyway. Most of the time that won't make a difference but perhaps obj1 has a dependency on something you do when initialising obj2 (or on obj2 itself) which won't have happened yet.

[Andreas Masur]

While dealing with initialization lists you should always keep one thing in mind. According to the standard class members get initialized in the order they are declared not in the order they appear in the initialization list...

class CFoo
{
public:
  CFoo(int iValueOne, int iValueTwo);

private:
  int m_iValueOne;
  int m_iValueTwo;
};

CFoo::CFoo(int iValueOne, int iValueTwo) : m_iValueTwo(iValueTwo), m_iValueOne(iValueOne) { ... }

In this case 'm_iValueOne' gets initialized first although 'm_iValueTwo' is standing first within the initialization list. That standard behaviour can cause problems which are hard to find... To avoid this you should always use the same order at declaration and initialization time...

This can result in severe problems if you want to initialize one member with another...

[treuss]

Standard says: Class members are initialized in the order of declaration. Fine.
But, why is it not advisiable to do the above???

I think it is also important to note, that class members are destroyed in the reverse order they are declared. Generally a good idea to destroy the members in the reverse order, they have been created (in case of dependencies).
So if you could override the oder in which the class members are initialized (like you try in your example), the members would not get destroyed any more in the reverse order they have been created. That's why the standard fixes both the order of creation and destroying to the declaration, not to the implementation of any of the constructors.

[Bond]

I think it is also important to note, that class members are destroyed in the reverse order they are declared. Generally a good idea to destroy the members in the reverse order, they have been created (in case of dependencies).
So if you could override the oder in which the class members are initialized (like you try in your example), the members would not get destroyed any more in the reverse order they have been created. That's why the standard fixes both the order of creation and destroying to the declaration, not to the implementation of any of the constructors.

The standard could have just as easily taken into account the order that the objects were initialized in the constructor initialization list and reversed that when destructing. I imagine the reason it doesn't is because you may have multiple constructors, each with a different initialization order. If that was the case, it would be impossible to know the order for destruction, unless it kept track of which constructor was used!

[SuperKoko]

The standard could have just as easily taken into account the order that the objects were initialized in the constructor initialization list and reversed that when destructing. I imagine the reason it doesn't is because you may have multiple constructors, each with a different initialization order. If that was the case, it would be impossible to know the order for destruction, unless it kept track of which constructor was used!

It is even a little more complex, because even if there was only one constructor, the module containing the constructor definition may be different than the module containing the destructor definition, what implies that the compiler would be constrained to store this order in some static data exported (put in a read-only data section for example) from the constructor's module containing necessary informations on the order of construction.

[Vedam Shashank]

Thanks for the inputs.