成员初始化表
#include <string>
class Account {
public:
Account();
Account( const char*, double=0.0 );
Account( const string&, double=0.0 );
Account( const Account& );
// ...
private:
// ...
};
//注意:构造函数的初始化列表只在构造函数的定义中指定,而不在声明中指定
inline Account::Account( const char* name, double opening_bal )
: _name( name ), _balance( opening_bal )
{
_acct_nmbr = get_unique_acct_nmbr();
}
成员初始化列表跟在构造函数的原型后,以冒号开头。成员名是被指定的,后面是括在括号中的初始值,类似于函数调用的语法。如果成员是类对象,则初始值变成被传递给适当的构造函数的实参,该构造函数然后被应用在成员类对象上。在我们的例子中,name被传递给应用在_name上的string构造函数,_balance 用参数opening_bal 初始化。类似地,下面是另一个双参数Account构造函数:
inline Account::Account( const string& name, double opening_bal )
: _name( name ), _balance( opening_bal )
{
_acct_nmbr = get_unique_acct_nmbr();
}
在这种情况下,string的拷贝构造函数被调用,把成员类对象_name 初始化成string 参数name。
C++新手关注的一个常见问题是,使用初始化列表和在构造函数内使用数据成员的赋值之间有什么区别。例如,以下代码:
inline Account::Account( const char *name, double opening_bal )
: _name( name ), _balance( opening_bal )
{
_acct_nmbr = get_unique_acct_nmbr();
}
和
inline Account::Account( const char *name, double opening_bal )
{
_name = name;
_balance = opening_bal;
_acct_nmbr = get_unique_acct_nmbr();
}
它们的区别是什么?
两种实现的最终结果是一样的。在两个构造函数调用的结束处,三个成员都含有相同的值,区别是成员初始化表只提供该类数据成员的初始化。在构造函数体内对数据成员设置值是一个赋值操作。区别的重要性取决于数据成员的类型。
在构造函数初始化列表中没有显示提及的每个成员,使用与初始化变量相同的规则来进行初始化。运行该类型的默认构造函数,来初始化类类型的数据成员。内置或复合类型的成员的初始值依赖于对象的作用域:在局部作用域中这些成员不被初始化,而在全局作用域中,它们被初始化为0(《c++ primer》4th p388)。
在概念上,我们可以认为构造函数的执行过程被分成两个阶段:隐式或显式初始化阶段,以及一般的计算阶段:
初始化阶段可以是显式的或隐式的,取决于是否存在成员初始化表。隐式初始化阶段按照声明的顺序依次调用所有基类的缺省构造函数,然后是所有成员类对象的缺省构造函数。
计算阶段由构造函数体内的所有语句构成。在计算阶段中,数据成员的设置被认为是赋值,而不是初始化。没有清楚地认识到这个区别是程序错误和低效的常见源泉。
例如,当我们写如下代码:
inline Account::Account()
{
_name = "";
_balance = 0.0;
_acct_nmbr = 0;
}
则初始化阶段是隐式的,在构造函数体被执行之前,先调用与_name相关联的缺省string构造函数,这意味着把空串赋给_name的赋值操作是没有必要的。
对于类对象,在初始化和赋值之间的区别是巨大的。成员类对象应该总是在成员初始化表中被初始化,而不是在构造函数体内被赋值。缺省Account构造函数的更正确的实现如下:
inline Account::Account() : _name( string() )
{
_balance = 0.0;
_acct_nmbr = 0;
}
它之所以更正确,是因为我们已经去掉了在构造函数体内不必要的对_name的赋值。但是,对于缺省构造函数的显式调用也是不必要的,下面是更紧凑但却等价的实现:
inline Account::Account()
{
_balance = 0.0;
_acct_nmbr = 0;
}
剩下的问题是,对于两个被声明为内置类型的数据成员,其初始化情况如何?例如,用成员初始化表和在构造函数体内初始化_balance 是否等价?回答是不。对于非类数据成员的初始化或赋值,除了两个例外,两者在结果和性能上都是等价的。更受欢迎的实现是用成员切始化表:
// 更受欢迎的初始化风格
inline Account::Account() : _balanae( 0.0 ), _acct_nmbr( 0 )
{ }
两个例外是指任何类型的const 和引用数据成员。const 和引用数据成员也必须是在成员初始化表中被初始化,否则,就会产生编译时刻错误。例如,下列构造函数的实现将导致编译时刻错误:
class ConstRef {
public:
ConstRef( int ii );
private:
int i;
const int ci;
int &ri;
};
ConstRef::ConstRef( int ii )
{ // 赋值
i = ii; // ok
ci = ii; // 错误: 不能给一个 const 赋值
ri = i; // 错误 ri 没有被初始化
}
当构造函数体开始执行时,所有const 和引用的初始化必须都已经发生。因此,只有将它们在成员初始化表中指定这才有可能。正确的实现如下:
// ok: 初始化引用和 const
ConstRef::ConstRef( int ii ):ci( ii ), ri( i )
{ i = ii; }
每个成员在成员初始化表中只能出现一次,初始化的顺序不是由名字在初始化表中的顺序决定,而是由成员在类中被声明的顺序决定的。例如,给出下面的Account 数据成员的声明顺序:
class Account {
public:
// ...
private:
unsigned int _acct_nmbr;
double _balance;
string _name;
};
下面的缺省构造函数:
inline Account::
Account() : _name( string() ), _balance( 0.0 ), _acct_nmbr( 0 )
{}
的初始化顺序为_acct_nmbr、_balance,然后是_name。但是在初始化表中出现(或者在被隐式初始化的成员类对象中)的成员,总是在构造函数体内成员的赋值之前被初始化。例如,在下面的构造函数中:
inline Account::Account( const char *name, double bal )
: _name( name ), _balance( bal )
{
_acct_nmbr = get_unique_acct_nmbr();
}
初始化的顺序是_balance、_name,然后是_acct_nmbr。
由于这种“实际的初始化顺序”与“初始化表内的顺序”之间的明显不一致,有可能导致以下难于发现的错误,当用一个类成员初始化另一个时:
class X {
int i;
int j;
public:
// 喔! 你看到问题了吗?
X( int val ): j( val ), i( j )
{}
// ...
};
尽管看起来j 好像是用val 初始化的,而且发生在它被用来初始化i之前,但实际上是i先被初始化的,因此它是用一个还没有被初始化的j 初始化的。我们的建议是,把“用一个成员对另一个成员进行初始化(如果你真的认为有必要)”的代码放到构造函数体内。
补充:
为了让你的程序能够顺利编译,在下面4种情况下,必须使用member initialization list:
n 当初始化一个reference member时;
n 当初始化一个const member时;
当类成员中含有一个const对象时,或者是一个引用时,他们也必须要通过成员初始化列表进行初始化,因为这两种对象要在声明后马上初始化,而在构造函数中,做的是对它们的赋值,这样是不被允许的。
n 当调用一个base class的constructor,而它拥有一组参数时;
n 当调用一个member class的constructor,而它拥有一组参数时;
我们知道类的对象的初始化其实就是调用它的构造函数完成,如果没有写构造函数,编译器会为你默认生成一个。如果你自定义了带参数的构造函数,那么编译器将不生成默认构造函数。这样这个类的对象的初始化必须有参数。如果这样的类的对象来做另外某个类的成员,那么为了初始化这个成员,你必须为这个类的对象的构造函数传递一个参数。同样,如果你在包含它的这个类的构造函数里用“=”,其实是为这个对象“赋值”而非“初始化”它。所以一个类里的所有构造函数都是有参数的,那么这样的类如果做为别的类的成员变量,你必须显式的初始化它,你也只能通过成员初始化列表来完成初始化。
参考材料:
《c++ primer》3th、4th
《深度探索C++对象模型》