http://blog.chinaunix.net/uid-25872711-id-3013871.html
http://blog.chinaunix.net/uid-25872711-id-3014567.html
Efficient C++ 第二章
Constructors and Destructors 构造函数和析构函数
理想情况下，构造和析构函数没有额外开销。但是实际上，尤其当类存在组合和继承的情况，它们可能会执行我们很少用到或者根本不会用到的运算。
继承
这一节我们来检验继承结构类的构造函数和析构函数的开销，用多线程同步的例子来为这一节做分析。线程同步通常用以下方式实现：semaphore，mutex，critical section。
多线程开发中为了使资源有序的使用，防止出现脏读，写回等情况，通常使用临界区。如：
get_the_lock(queueLock);
...
numberOfElements++;
...
release_the_lock(queueLock);
线程获得锁，函数调用完成一定要释放锁，否则程序异常。开发中，存在这样的情况，函数调用起始时加锁，之后函数中有100条语句，并且其中很多条件return点。这样为了保证函数返回释放锁，那么我们每个return点之前都必须要加上释放锁的代码。这样写起来相当麻烦。
C++对这类问题提供了相当精彩的解决方案，将加锁和释放锁封装到类的构造和析构函数中，这样只要函数调用时构造锁类实例加锁，函数任何一个调用结束点之前都会自动调用实例的析构函数来销毁局部变量。比如代码：
class Lock {
public:
Lock(pthread_mutex_t& key)
: theKey(key) { pthread_mutex_lock(&theKey);
}
~Lock() { pthread_mutex_unlock(&theKey); }
private:
pthread_mutex_t &theKey;
};
为了使程序支持多种类型的锁，我们做如下继承结构：
//锁的基类
class BaseLock {
public:
// (The LogSource object will be explained shortly)
BaseLock(pthread_mutex_t &key, LogSource &lsrc) {};
virtual ~BaseLock() {};
};
//MutexLock
class MutexLock : public BaseLock {
public:
MutexLock (pthread_mutex_t &key, LogSource &lsrc);
~MutexLock();
private:
pthread_mutex_t &theKey;
LogSource &src;
};
//实现
MutexLock::MutexLock(pthread_mutex_t& aKey, const LogSource& source)
: BaseLock(aKey, source),
theKey(aKey),
src(source)
{
pthread_mutex_lock(&theKey);
#if defined(DEBUG)
cout << "MutexLock " << &aKey << " created at " << src.file() <<
"line" <<src.line() << endl;
#endif
}
MutexLock::~MutexLock() // Destructor
{
pthread_mutex_unlock(&theKey);
#if defined(DEBUG)
cout << "MutexLock " << &aKey << " destroyed at " << src.file()<<
"line" << src.line() << endl;
#endif
}
//LogSource类实现
class BaseLogSource {
public:
BaseLogSource() {}
virtual ~BaseLogSource() {}
};
class LogSource : public BaseLogSource {
public:
LogSource(const char *name, int num) : filename(name),
lineNum(num) {}
~LogSource() {}
char *file();
int line();
private:
char *filename;
int lineNum;
};
//假设我们做如下调用
{
MutexLock myLock(theKey, LogSource(__FILE__, __LINE__));
sharedCounter++;
}
以上实现有如下开销：
1）调用BaseLogSource构造函数
2）调用LogSource构造函数
3）调用BaseLock构造函数
4）调用MutexLock构造函数
5）函数调用结束前，再分别调用析构函数
6）MutexLock析构函数
7）BaseLock析构函数
8）LogSource析构函数
9）BaseLogSource析构函数
但是实际上我们只需要如下加锁，解锁的开销：
{
pthread_mutex_lock(&theKey);
sharedCounter++;
pthread_mutex_unlock(&theKey);
}
可以看到LogSource使用前都加上#if defined(DEBUG)，只有DEBUG宏打开的时候LogSource才会使用，所以很多时候LogSource和其基类构造、析构的开销是不需要的。
开销测试
使用如下几个版本做开销测试：
int main()// Version 1
{
...
// Start timing here
for (i = 0; i < 1000000; i++) {
pthread_mutex_lock(&mutex);
sharedCounter++;
pthread_mutex_unlock(&mutex);
}
// Stop timing here
...
}
int main() // Version 2
{
...
// Start timing here
for (i = 0; i < 1000000; i++) {
SimpleMutex m(mutex);
sharedCounter++;
}
// Stop timing here
...
}
class SimpleMutex // Version two. Standalone lock class.
{
public:
SimpleMutex(pthread_mutex_t& lock) : myLock(lock) {acquire();}
~SimpleMutex() {release();}
private:
int acquire() {return pthread_mutex_lock(&myLock);}
int release() {return pthread_mutex_unlock(&myLock);}
pthread_mutex_t& myLock;
};
class BaseMutex // Version 3. Base class.
{
public:
BaseMutex(pthread_mutex_t& lock) {};
virtual ~BaseMutex() {};
};
class DerivedMutex: public BaseMutex // Version 3.
{
public:
DerivedMutex(pthread_mutex_t& lock)
: BaseMutex(lock), myLock(lock) {acquire();}
~DerivedMutex() {release();}
private:
int acquire() {return pthread_mutex_lock(&myLock);}
int release() {return pthread_mutex_unlock(&myLock);}
pthread_mutex_t& myLock;
};
int main() // Version 3
{
...
// Start timing here
for (i = 0; i < 1000000; i++) {
DerivedMutex m(mutex);
sharedCounter++;
}
// Stop timing here
...
}
测试结果，v1和v2分别耗时1.01s左右，而v3为1.62s，效率降低了近60%。继承中不必要的基类构造和析构造成了不小的开销，但是这也不能说继承就是影响效率不能使用的结构。我们应该正确区分开销：
1）全部开销
2）必要开销
3）其它开销，正常情况其它开销是可以通过优化消除的。
举例来看：
class SimpleMutex
{
public:
SimpleMutex(pthread_mutex_t& lock) : myLock(lock) {acquire();}
~SimpleMutex() {release();}
private:
int acquire() {return pthread_mutex_lock(&myLock);}
int release() {return pthread_mutex_unlock(&myLock);}
pthread_mutex_t& myLock;
};
构造函数中的全部开销为：
1）初始化myLock
2）调用acquire()
3）acquire中调用pthread_mutex_lock加锁
加锁是必要开销，第一项是其它开销这是面向对象的结构导致的。
组合
类型中包含另外一个类型的实例做成员，这叫做组合。类的构造函数会对类的所有成员做初始化，自动调用类实例成员的构造函数。如果实例成员类中再包含另外的类实例成员，那么这会构成一棵组合树。如何不多加注意，组合树的规模会很大，而且开销相当可观。
还是以Trace为例，对比如下实现方式：
1. 类中有string实例，构造函数会调用string的构造函数
class Trace {
public:
Trace (const char *name);
...
private:
string theFunctionName;
};
2. 将string实例换为string指针，但是仍做完成初始化，调用构造函数
class Trace {
public:
Trace (const char *name);
// ...
private:
string *theFunctionName;
};
Trace::Trace(char *name) : theFunctionName(new string(name))
{
...
}
3. 修改实现，先将指针赋0，Trace为active后再调用构造函数
Trace::Trace (const char *name) : theFunctionName(0)
{
if (traceIsActive) {
theFunctionName = new string(name);
...
}
}
通常情况下，Trace是非active的，那么方案1、2都是很低效的，因为每次创建Trace实例都会调用String构造函数造成不必要开销。但是，如果string值是经常或者每次都必要的，那么方案1是最高效的，因为实例是分配到栈上，而方案3中实例分配在堆上，在堆上alloc和free比栈上开销大的多，栈上内存是编译时刻分配的，函数返回阶段自动释放。
（这里需要注意：如果Trace本身分配在堆上，那么即使string成员为实例，它也是分配在堆上不是栈上的。）
Lazy Construction
C语言中，所有变量的定义必须在函数的开头，但是在C++中这是不好的习惯。这导致很多时候，有一些局部变量在函数调用结束都从未被使用过。比如：
class DataPacket
{
public:
DataPacket(char *data, int sz) : size(sz) {
buffer = new char[sz];
...
}
~DataPacket() {
delete [] buffer;
...
}
... // other public member functions
private:
char *buffer;
... // other private members
};
DataPacket用于分配回收内存，对内存集中利用。它的构造和析构开销都比较大，有如下的使用情境：
void routeData(char *data, int size)
{
DataPacket packet(data, size);
bool direction = get_direction();
... // Some computation
if (UPSTREAM == direction) {// data going upstream
computeSomething(packet);
}
else { // data going downstream
... // packet is not used in this scope.
}
}
可以看出，packet只有50%的概率能用到，也就是说有一半情况下做了DtaPacket分配释放的无用开销。应该把实例初始放到if语句内部，减小无用开销。因为C变量定义时没有运行时开销，这让C程序员形成这种编程习惯，但是C++中完全不是这样。
Redundant Construct 冗余构造
有如下情况：
class Person {
public:
Person (const char *s) { name = s; }// Version 0
...
private:
string name;
};
上面的构造函数中，首先构造函数调用之前会对成员进行初始，调用string的构造函数构造空的string。然后执行构造函数又通过string::operator=(const char*)操作，重新赋值给name。这就造成了冗余构造，string实例完成可以在构造函数初始化表里一步完成初始化。
做如下修改：
Person::Person(const char *s) : name(s) {} // Version 1.
前后对比执行效率，发现相差不多，但是一定不能认为这种构造方式没问题，只能说string的构造开销非常小，如果是其它复杂类结果就不是这样了。
要点
1）对象创建（或清除），会引发其父类对象和包含成员对象的创建（或清除），要当心处理，减小不必要开销。
2）使用对象时才创建，不要在函数开始创建所有对象
3）注意类对象构造原则，不要在构造函数中做冗余操作