Guru of the Week 条款28：“Fast Pimpl”技术
GotW #28“Fast Pimpl”技术（The "Fast Pimpl" Idiom）
难度：6 / 10
采用一些称为“低依赖度”或“效能”方面的捷径，在很多时候颇有诱惑力，但它不总是好主意。这儿有个很精彩的方法能在客观上同时并安全的实现二者。
问题
标准的malloc()和new()调用的开销都是很大的。在下面的代码中，程序员最初在class Y中设计了一个类型X的成员：
// file y.h
#include "x.h"
class Y {
/*...*/
X x_;
};
// file y.cpp
Y::Y() {}
这个class Y的申明需要class X的申明已经可见（从x.h中）。要避免这个条件，程序员首先试图这么写：
// file y.h
class X;
class Y {
/*...*/
X* px_;
};
// file y.cpp
#include "x.h"
Y::Y() : px_( new X ) {}
Y::~Y() { delete px_; px_ = 0; }
这很好地隐藏了X，但它造成了：当Y被广泛使用时，动态内存分配上的开销降低了性能。最终，我们这无畏的程序员偶然间发现了“完美”解决方案：既不需要在y.h中包含x.h，也不需要动态内存分配（甚至连一个前向申明都不需要！）：
// file y.h
class Y {
/*...*/
static const size_t sizeofx = /*some value*/;
char x_[sizeofx];
};
// file y.cpp
#include "x.h"
Y::Y() {
assert( sizeofx >= sizeof(X) );
new (&x_[0]) X;
}
Y::~Y() {
(reinterpret_cast<X*>(&x_[0]))->~X();
}
讨论
解答
简短的答案
不要这样做。底线：C++不直接支持不定类型（opaque types），这是依赖于这一局限上的脆弱尝试（有些人甚至称此为“hack”[注1]）。
程序员期望的肯定是其它一些东西，它被称为“Fast Pimpl”方法，我将在“为什么尝试3是糟糕的”一节中介绍。
为什么尝试3是糟糕的
首先，让我们稍许考虑一下为什么上面的尝试3是糟糕的，从以下方面：
1. 对齐。不象从::operator new()得到的动态内存，这个x_的字符buffer并不确保满足类型X的对齐要求。试图
让x_工作得更可靠，程序员需要使用一个“max_align”联合，它的实现如下：
union max_align {
short dummy0;
long dummy1;
double dummy2;
long double dummy3;
void* dummy4;
/*...and pointers to functions, pointers to
member functions, pointers to member data,
pointers to classes, eye of newt, ...*/
};
它需要这样使用：
union {
max_align m;
char x_[sizeofx];
};
这不确保完全可移植，但在实际使用中，已经足够完美了，只在极少的系统（也可能没有）上，它不能如愿工作。
我知道有些老手认可甚至推荐这种技巧。凭良心，我还是称之为hack，并强烈反对它。
2.脆弱。Y的作者必须极度小心处理Y的其它普通函数。例如，Y绝不能使用默认赋值操作，必须禁止它或自己提供一个版本。
写一个安全的Y::operator=()不是很难，我把它留给读者作为习题。记得在这个操作和Y::~Y()中考虑异常安全的需求。当你完成后，我想，你会同意这个方法制造的麻烦比它带来的好处远为严重。
3.维护代价。当sizeof(X)增大到超过sizeofx，程序员必须增大sizeofx。这是一个没有引起注意的维护负担。选择一个较大的sizeofx值可以减轻这个负担，但换来了效能方面的损失（见#4）。
4.低效能的。只要sizeofx大于sizeof(X)，空间被浪费了。这个损失可以降到最小，但又造成了维护负担（见#3）。
5.顽固不化。我把它放在最后，但不是最轻：简而言之，明显，程序员试图做些“与众不同”的事情。说实话，在我的经验中，“与众不同”和“hack”几乎是同意词。无论何时，只要见到这种“颠覆”行为－－如本例的在字符数组中分配对象，或GotW#23中谈到的用显式的析构加placement new来实现赋值－－，你都一定要说“No”。
我就是这个意思。好好反思一下。
更好的解决方法：“Fast Pimpl”
隐藏X的动机是避免Y的用户必须要知道（于是也就依赖）X。C++社区中，为了消除这种实现依赖，通常使用“pimpl”方法（注2），也就是我们这个无畏的程序员最初所尝试的方法。
唯一的问题是，“pimpl”方法由于为X的对象在自由空间分配内存而导致性能下降。通常，对特殊类的内存分配性能问题，采用为它提供一个operator new的重载版本的方法，因为固定尺寸的内存分配器可以比通用内存分配器性能高得多。
不幸的是，这也意味着Y的作者必须也是X的作者。通常，这不成立。真正的解决方法是使用一个高效的Pimpl，也就是，有自己的类属operator new的pimpl类。
// file y.h
class YImpl;
class Y {
/*...*/
YImpl* pimpl_;
};
// file y.cpp
#include "x.h"
struct YImpl { // yes, 'struct' is allowed :-)
/*...private stuff here...*/
void* operator new( size_t ) { /*...*/ }
void operator delete( void* ) { /*...*/ }
};
Y::Y() : pimpl_( new YImpl ) {}
Y::~Y() { delete pimpl_; pimpl_ = 0; }
“啊！”你叫道，“我们找到了圣杯－－Fast Pimpl！”。好，是的，但先等一下，先想一下它是如何工作的，并且它的代价是什么。
你所收藏的C++宝典中肯定展示了如何实现一个高效的固定尺寸内存分配/释放函数，所以我就不多罗嗦了。我要讨论的是“可用性”：一个技巧，将它们放入一个通用固定尺寸内存分配器模板中的技巧，如下：
template<size_t S>
class FixedAllocator {
public:
void* Allocate( /*requested size is always S*/ );
void Deallocate( void* );
private:
/*...implemented using statics?...*/
};
因为它的私有细节很可能使用static来实现，于是，问题是Deallocate()是否被一个static对象的析构函数调用（Because the private details are likely to use statics, however, there could be problems if Deallocate() is ever called from a static object's dtor）。也许更安全的方法是使用single模式，为每个被请求的尺寸使用一个独立链表，并用一个唯一对象来管理所有这些链表（或者，作为效能上的折中，为每个尺寸“桶”使用一个链表；如，一个链表管理大小在0～8的内存块，另一个链表表管理大小在9～16的内存块，等等。）：
class FixedAllocator {
public:
static FixedAllocator* Instance();
void* Allocate( size_t );
void Deallocate( void* );
private:
/*...singleton implementation, typically
with easier-to-manage statics than
the templated alternative above...*/
};
让我们用一个辅助基类来封装这些调用：
struct FastPimpl {
void* operator new( size_t s ) {
return FixedAllocator::Instance()->Allocate(s);
}
void operator delete( void* p ) {
FixedAllocator::Instance()->Deallocate(p);
}
};
现在，你可以很容易地写出你任意的Fast Pimpl：
// Want this one to be a Fast Pimpl?
// Easy, then just inherit...
struct YImpl : FastPimpl {
/*...private stuff here...*/
};
但，小心！
这虽然很好，但也别乱用Fast Pimpl。你得到了最佳的内存分配速度，但被望了代价：维护这些独立的链表将导致空间效能的下降，因为这比通常情况现成更多的内存碎片（Managing separate free lists for objects of specific sizes usually means incurring a space efficiency penalty because any free space is fragmented (more than usual) across several lists）。
和其它性能优化方法一样，只有在使用了profiler剖析性能并证明需要性能优化后，才使用这个方法。
（注1. 我不是其中之一。 :-））
（注2. 参见GotW #24.）
