public: ConstRef( int ii ); private: int i; const int ci; int &ri; }; ConstRef:: ConstRef( int ii ) { // assignment i = ii; // ok ci = ii; // error: cannot assign to a const ri = i; // error: ri is uninitialized }

By the time the body of the constructor begins executing, the initialization of all const and reference class data members must have already taken place This can be done only by specifying them in the member initialization list A correct implementation is the following:

// ok: initialize reference and const ConstRef:: ConstRef( int ii ) : ci( ii ), ri( i ) { i = ii; }

Each member may be named only once in the member initialization list The order of initialization is determined not by the order of names in the initialization list but by the class declaration order of the members For example, given the following declaration order of the Account data members,

class Account { public: // private: unsigned int _acct_nmbr; double _balance; string _name; };

inline Account:: Account() : _name( string() ), _balance( 00 ), _acct_nmbr( 0 ) {}

is _acct_nmbr, _balance, then _name However, the members named in the initialization list (or in an implicitly initialized

file:///F|/WinDDK/resources/CPPPrimer/c++primerhtm (655 / 1065) [2001-3-29 11:32:11]

member class object) are always initialized prior to the assignment of members within the body of the constructor For example, in the following constructor,

inline Account:: Account( const char *name, double bal ) : _name( name ), _balance( bal ) { _acct_nmbr = get_unique_acct_nmbr(); }

the order of initialization is _balance, _name, then _acct_nmbr This apparent anomaly between the initialization order and the order within the initialization list can lead to the following difficult-touncover error when using one class member to intialize another:

class X { int i; int j; public: // oops! do you see the problem X( int val ) : j( val ), i( j ) {} // };

Although it looks as if j is initialized with val, prior to being used to initialize i, in fact i is initialized first and is therefore initialized with the as yet uninitialized j Our recommendation is always to place the initialization of one member with another (if you really feel that it is necessary) within the body of the constructor, as follows:

// preferred idiom X::X( int val ) : i( val ) { j = i; }

Exercise 1412 What, if anything, is wrong with the following constructor definitions How would you fix those identified as wrong

(a) Word::Word( char *ps, int count = 1 ) : _ps( new char[strlen(ps)+1] ), _count( count ) { if ( ps ) strcpy( _ps, ps ); else { _ps = 0; _count = 0;

file:///F|/WinDDK/resources/CPPPrimer/c++primerhtm (656 / 1065) [2001-3-29 11:32:11]

} } (b) class CL1 { public: CL1() { creal(00); cimag(00); s = "not set"; } // private: complex<double> c; string s; }; (c) class CL2 { public: CL2( map<string,location> *pmap, string key ) : _text( key ), _loc( (*pmap)[key] ) {} // private: location _loc; string _text; };

Account oldAcct( "Anna Livia Plurabelle" ); Account newAcct( oldAcct );

is referred to as default memberwise initialization Default because it occurs automatically whether or not we supply an explicit constructor Memberwise because the unit of initialization is the individual nonstatic data member rather than a bitwise copy of the entire class object The most simple conceptual model of memberwise initialization is to think of the compiler generating a special class copy constructor internally Within the copy constructor, each nonstatic data member in turn is initialized in the order of declaration For example, given our first definition of the Account class

class Account { public: // private: char *_name; unsigned int _acct_nmbr; double _balance; };

the default Account copy constructor can be thought of as being defined as follows:

file:///F|/WinDDK/resources/CPPPrimer/c++primerhtm (657 / 1065) [2001-3-29 11:32:11]