logic behind initializer list

[danicpp]

Well if I have code like

class a{//interface}; //implementation for class "a"

class b{//interface has a member of type "a"}; //implementation constructor must have an initializer for object of type "a"

now my teacher told, said in his video(as I'm in a distance learning system) the reason is sequence in which objects are created
1. first inner objects are created i.e. here type "a" object will be created before the creation of object of "b" class which means constructor for "a" will have to be called before the constructor of "b"

2. after creation of inner objects main object is created

AND destruction sequence is opposite of this

Question:
1. can this sequence be different i.e creating outer objects first as compiler already know the seizes of objects included as they are already defined

2. I assume if we don't use initializer list still the objects would be created but for inner objects, default constructor will be called and latter inside main object's constructor the value will be changed, Would this happen??? if no why?

[kbw]

1. No. It's not about sizes of things. It's about creating new types.
2. Yes.

[danicpp]

well thanks kbw for answering, but

1. No. It's not about sizes of things. It's about creating new types.

it's about sizes of things which compiler know (why, because their sizes have already been defined in class interface) so if compiler knows the sizes it can do following

Main Size = {sum of sizes of inner objects}

now you know the size of Main allot memory for main first then within this main memory allot memories for inner objects quite simple

[Zhuge]

The constructor for b may depend on data in a, manipulating it or using it to initialize some of its own data. So a would have to be constructed first in order to allow this.

[danicpp]

Oh yess!!! this makes sense like

B::B(){

      aobj.somework();
}

yes for sure for this to work the a type object first must exist.

thanks