Assuming the question is about construction of an object in a class hierarchy, Edward has trouble answering questions that are answered easily by Ed's intuition. Why does it not make sense for the base parts of an object to be constructed before the derived parts?

Edited 6 Years Ago by Radical Edward: n/a

Ya in a class hierarchy ... Why the order of execution of the constructor is from base class then to its derived class

I don't really see how knowing "why" actually helps, although if you think about what inheritance represents, it should be obvious - a base class represents generalised components which are common to all objects in a heirarchy - essentially a base class is a 'sub set' of its derived classes - it makes sense that the common subset is created first before the specialisations.

I have beeen thinking what are the problems when constructors are called from bottom to top?? Could you think of any ?

Well the main problem with starting the construction of a class from the derived part up to the base is that any variables you are using that are in your base in a function in your derived class would be undefined. Assume this situation.

class A
{
    int number;
};

class B : public A
{
    void foo() { number++; }
};

In this situation the compiler would have no idea what number is when it tried to compile it if it were to start at B and go to A. Since it goes the other way there is no problem.

Well the main problem with starting the construction of a class from the derived part up to the base is that any variables you are using that are in your base in a function in your derived class would be undefined. Assume this situation.

class A
{
    int number;
};

class B : public A
{
    void foo() { number++; }
};

In this situation the compiler would have no idea what number is when it tried to compile it if it were to start at B and go to A. Since it goes the other way there is no problem.

Construction order has nothing to do with the compiler - object initialisation happens at run time. Also, your code still has problems in that number is undefined by the base class irrespective of the order that the classes are constructed.
And lastly, foo is not a constructor, nor is it called by any constructors so is not involved in the construction order anyway.

A better example to illustrate construction order might be this

class A
{
    int number;
public:
    A(int n) : number(n) {}
    void display()
    {
        std::cout << number;
    }
};

class B : public A
{
public:
    B(int n) : A(n) 
    {
        display();
    }
};

If the rule were that B must be fully constructed before creation of A can commence, then the constructor for B would have had to finish before A(n) is called - however, display() relies on A::number being well defined.

However, if it were the other way around, i'm sure that C++ would have had safeguards defined to stop code like this - C++'s behaviour is the same as every other OO language out there - i.e. things are like this 'because the OO paradigm says so'.

Edited 6 Years Ago by Bench: n/a

Construction order has nothing to do with the compiler

Sorry, that's poorly worded; what I meant was "object construction doesn't happen at compile time".

So its like you can draw a dependancy graph for this and the topological order is from base to derived . So the compiler follows this convention

This question has already been answered. Start a new discussion instead.