Initializing inner-objects of base class from the driven-class constructor

**Dave11** · 01-06-2015

my question as follows:

let's say I have a Car object , and it contains inner Engine object.

Code:

struct Car{
Engine mEngine;
};

in order to initialize the engine object NOT by the default constructor (if it has any) , we use initialization semantics:

Code:

Car::Car:
mEngin(arg1,arg2,...)
{
other stuff here
}

now it gets tricky:
let's say a Car objects has 10 inner objects, each object has about 5 variables in it . Car is a base class for , e.g. , Toyota class. you don't want the Car class to have a constructor with 50 arguments.
can the inner objects of Car be initialized from the base class , e.g. Toyota?

Code:

class Toyota:
Car(...),
mEngine(...),
mGear(..)
{
...
};

the other options are:
1) like said , create a Car constructor which gets 50 arguments, then initialize Car as whole from Toyota - the code becomes less readable and less intuitive
2) Car constructor which get built-objects as arguments and initialize the inner objects with copy constructor . the code gets more readable but then you create many excess objects .
I don't like either of these sulotions.

**laserlight** · 01-06-2015

Originally Posted by Dave11

2) Car constructor which get built-objects as arguments and initialize the inner objects with copy constructor . the code gets more readable but then you create many excess objects .

This is the way to go, except that instead of the copy constructor the move constructor for the member objects could be implemented and used to avoid unnecessary deep copying.

**grumpy** · 01-06-2015

Firstly, the Engine member of your Car class is not an "inner object". The Car might be an aggregate of objects, one of which might be an engine. In C++, the Engine might be described as a member of the Car. It is not an "inner object".

Second, a derived class does not need to directly initialise members of a base class - and, in practice, very rarely will. The derived class constructor will always invoke a base class constructor, either explicitly (i.e. via initialiser list) or implicitly (the compiler works out which constructor needs to be invoked). (A derived class may need to explicitly initialise virtual bases, but that's not what you are referring to - and is different from initialising members of a base class directly).

There is nothing preventing a constructor, of any class, from accepting arguments that are of struct/class type (e.g. a struct that contains data to initialise several parts that will be components of a car) or a collection (for example, a vector containing various components). All the implementation of derived class constructor needs to do is selectively pass parameters it receives on to the base class.

As laserlight said, the second way you describe is the way to go.

Part of the skill (or the art form) of designing classes is avoiding undue complexity in how they are initialised (or, for that matter, how they are used). From your complaint, I suspect that is where you need to focus attention and learn. The only "excess objects" you need to worry about are those which you have put into your design "just in case" when they are not needed. If an object (or object type) is needed, then it is needed .... and, by definition, it is not excess.

**Dave11** · 01-06-2015

By excess I mean temporary objects that will be deleted when the copying is over , thus wasting (temporarily) memory and increase running time.
but then , computers are strong and fast today , and smart compilers will optimize all of the construction to death anyway..

thanks all!

**grumpy** · 01-06-2015

Originally Posted by Dave11

By excess I mean temporary objects that will be deleted when the copying is over , thus wasting (temporarily) memory and increase running time.

Even on old machines, such temporaries are rarely significant. In order to use a value, or a set of values, or an organised set of named values (aka a struct) to initialise something else, it is necessary to copy the values around. That is just as true in either of the ways you describe.

**Elysia** · 01-06-2015

Originally Posted by Dave11

By excess I mean temporary objects that will be deleted when the copying is over , thus wasting (temporarily) memory and increase running time.

That is what move semantics were made for.

Thread: Initializing inner-objects of base class from the driven-class constructor

Thread Tools

Search Thread

Display

Initializing inner-objects of base class from the driven-class constructor

Similar Threads

nitializing parent Class's member variables from base's --- Base's Constructor

Do you need to call Base class's Copy Constructor in a Derived class?

Initializing members of base class

base class pointer to derived class objects

Calling constructor of the base class of a derived class..