Issues related to the initialization list of c ++ class members

Issues related to the initialization list of c ++ class members

In the following four cases, you must use the member initialization list to smoothly compile the program ):

1. initialize a reference member );

2. initialize a constant object (const member );

3. Call a base class constructor, and the base class constructor has a set of parameters;

4. Call the constructor of a member class. The constructor has a set of parameters.

In these four cases, the program can be compiled normally, but the efficiency is poor (as described below ).

Class Word {

String _ name;

Int _ cnt;

Public:

Word (){

_ Name = 0;

_ Cnt = 0;

}

};

The implementation mechanism of the above program is: the constructor of the Word class will generate a temporary object of the String class (note that _ name is the object of the String class ), then initialize the temporary object.

Then, assign the temporary object to _ name through the value assignment operator, and finally parse the temporary object.

The internal expansion result of the constructor is as follows:

Word: Word ()

{

_ Name. String: String (); // call the default constructor of the String class)

String temp = String (0); // generate a temporary object of the class and initialize it.

_ Name. String: operator = (temp); // use the value assignment operator to copy the value (depth) of a temporary object to _ name

Temp. String ::~ String (); // call the String destructor

_ Cnt = 0;

}

The above code is not highly efficient, because you need to call the default constructor and destructor in the middle to generate and destroy a temporary object. The following is a more efficient implementation method:

Word: _ name (0) // _ name directly calls the String class constructor to assign values to it

{

_ Cnt = 0;

}

It will be expanded by the constructor into the following forms (c ++ pseudo code)

Word: Word ()

{

_ Name. Sting: String (0); // call the String (int) constructor.

_ Cnt = 0;

}

The member initialization list is not a set of function calls. The Compiler operates the initialization list one by one and inserts initialization operations in the constructor in an appropriate order, it is performed before the programmer explicitly writes the code.

The project order in the list is determined by the Declaration Order of the members in the class, not by the arrangement order in the initialization list. Unexpected errors may occur due to the disorder of "initialization order" and "project arrangement order in the initialization list:

Class X {

Int I;

Int j;

Public:

X (int value): j (value), I (j)

{}....

}; The original intention of the code writer is to set the initial value of j to value, and then set the initial value of I to j. However, since the declared order I is before j, I (j) in the initialization list is actually executed earlier than j (value,

This leads to unexpected errors. The correct statement should be:

Class X {

Int I;

Int j;

Public:

X (int value): j (value) // j (value) Call the constructor to assign the initial value.

{I = j ;}

};

Although this statement is still written before j, there is no error because the items in the initialization list are inserted into the constructor and the original declaration order is not maintained, that is to say, the project order in the initialization list inserted to the constructor initialization list has a higher priority than the Order explicitly declared by the code writer.