文章来自于The “Empty Member” C++ Optimization。是我在看c++ std::string代码时遇到的一个链接，其中解释了为什么_Alloc_hider会采纳inhert from Alloc的起因。
文章应该是97年的，所以外面的指针长度还是4 byte。
c++类中“空成员”的优化
C++规范库中有很多有用的模板，包含享誉盛名的SGI STL。这些模板的实现很高效，也不失灵便。在日常的编程中，能够把这些模板当作范例来进行学习，也可启发咱们如何进行兼顾灵活性与效率的程序设计。
“空成员”的优化，就是这样的一个榜样：一个没有类成员的class，就不应该占用内存空间。什么状况下须要一个没有类成员的class呢？这样的class个别会领有一系列的typedef或者成员函数，而程序的调用方能够用本人定义的相似的class来实现一些非凡的性能（自定义的class可不肯定没有类成员）。这个默认提供的class应该能够满足绝大多数的需要。这种状况下，优化这个空成员的class是个很有性价比的事件。
因为语言的限度（之后会解释），空成员的class通常会占据肯定的内存空间。如果是个别状况也就算了，然而在stl里，不进行优化的话，还是会劝退很多潜在的使用者的。
空成员“收缩”
以STL举例。每个STL的容器都有一个allocator的参数，当容器须要内存的时候，它会向allocator去申请。如果用户想要本人定制化内存申请过程，那么就能够在结构容器时提供本人的allocator。大多数状况下，容器用的是STL默认的allocator，这个默认的allocator间接调用new来实现调配。这是个空类，相似于上面这个定义
template <class T>
class allocator { // an empty class
. . .
static T* allocate(size_t n)
{ return (T*) ::operator new(n * sizeof T); }
. . .
};举个list的例子，class list保留了一个公有的allocator成员，这个成员在构造函数里进行赋值
template <class T, class Alloc = allocator<T> >
class list {
. . .
Alloc alloc_;
struct Node { . . . };
Node* head_;
public:
explicit list(Alloc const& a = Alloc())
: alloc_(a) { . . . }
. . .
};成员list<>::alloc_通常占据4 byte，只管这个Alloc是个空类。这通常来说不太会是个问题。但万一list本身是一个微小的数据结构的一个节点（比方vector<list>)，当vector很大的时候，这种额定的空间耗费是不可漠视的。微小的内存占用意味着更慢的执行速度。就算在当下，绝对于cpu本身的频率来说，内存拜访曾经十分慢了。
空对象
那么改怎么解决这个问题？解决问题之前，首先须要搞清楚为什么这里会有这一层开销。C++的语言定义是这么说的：
A class with an empty sequence of members and base class objects is an empty class. Complete objects and member subobjects of an empty class type shall have nonzero size.
空类：没有数据成员，并且没有基类。这个基类实例化进去的残缺对象的大小不应该为0.
解释以下这个规定的原因：
struct Bar { };
struct Foo {
struct Bar a[2];
struct Bar b;
};
Foo f;那么f.b和f.a[]别离是什么？如果sizeof(Bar)是0，那么这2个地址就是一样的。如果你用地址来作为对象的标识，那么f.b和f.a[0]就是同一个对象了。C++规范委员会通过禁止空类的对象大小为0来解决这个问题。
但为什么还须要占据4 byte的大小呢？尽管大部分的编译器认为sizeof(Bar) == 1，但4 byte是对象对齐的需要。比方：
struct Baz {
Bar b;
int* p;
};构造体Baz在大多数的体系结构上大小是8 byte，编译器本人在Baz::b前面增加了补齐，是为了让Baz::p不会横跨一个字(word)。
struct Baz
+-----------------------------------+
| +-------+-------+-------+-------+ |
| | Bar b | XXXXX | XXXXX | XXXXX | |
| +-------+-------+-------+-------+ |
| +-------------------------------+ |
| | int* p | |
| +-------------------------------+ |
+-----------------------------------+那该如何躲避调这个额定的开销呢？C++规范也在Footnote里提了一嘴：
A base class subobject of an empty class type may have zero size.
空类作为基类时，其大小能够为0
也就是说，如果是这个构造体
struct Baz2 : Bar {
int* p;
};编译器就会认为Bar的大小为0，这样sizeof(Baz2)就是4。
struct Baz2
+-----------------------------------+
| +-------------------------------+ |
| | int* p | |
| +-------------------------------+ |
+-----------------------------------+编译器并未要求实现成这个样子，然而你能够认为大部分规范的编译器就是这样实现的。
打消收缩
当初你晓得了打消这个开销的原理了，问题是接下来怎么做？最直观的，list<>间接继承Allocator，如下：
template <class T, class Alloc = allocator<T> >
class list : private Alloc {
. . .
struct Node { . . . };
Node* head_;
public:
explicit list(Alloc const& a = Alloc())
: Alloc(a) { . . . }
. . .
};这当然是能够的。list里的成员函数能够间接调用this->allocate()，而非allco_.allocate()实现内存申请。
不过，用户提供的Alloc是容许领有虚函数的，这可能会和子类list<>里的某些办法有抵触。（list<>::init和Alloc::init())。
另一种可行的形式是，将Alloc打包到list<>的成员变量上(比方指向第一个list node的指针)，这样Allocator的接口不会裸露进去。
template <class T, class Alloc = allocator<T> >
class list {
. . .
struct Node { . . . };
struct P : public Alloc {
P(Alloc const& a) : Alloc(a), p(0) { }
Node* p;
};
P head_;
public:
explicit list(Alloc const& a = Alloc())
: head_(a) { . . . }
. . .
};采纳这种办法实现的话，申请内存就用head.allocate()。没有额定的开销，list<>用起来也和以前一样。不过就像其余做的好的优化一样，实现上总是有点俊俏，但总归不会影响到接口了。
对立一点的解决方案
当然还有晋升的空间了。看看上面这个template
template <class Base, class Member>
struct BaseOpt : Base {
Member m;
BaseOpt(Base const& b, Member const& mem)
: Base(b), m(mem) { }
};用这个模板，那么list的接口就能够变成这样：
template <class T, class Alloc = allocator<T> >
class list {
. . .
struct Node { . . . };
BaseOpt<Alloc,Node*> head_;
public:
explicit list(Alloc const& a = Alloc())
: head_(a,0) { . . . }
. . .
};这个实现相比与最开始的版本，看起来也没那么不堪了。其余的STL容器，也能够借助BaseOpt来简化代码。只不过，成员函数申请内存的时候就会奇怪一些了，这个咱们当初还临时不思考了。
当初能够在BaseOpt定义的中央加上很好的文档来形容这个优化技术了。
也能够在BaseOpt里增加一些成员，然而并不倡议这样做。这可能会造成和Base里名称抵触（就像咱们在第一次尝试打消收缩的代码里一样）。
收尾
这项技术能够在当下通用的编译器里应用。就算编译器没有实现空基类优化，也没有额定的开销。
发表回复