分配器 (C++)

title: 背景.
content: 亚历山大·斯特潘诺夫与李梦(Meng Lee)在1994年将标准模板库草案提交给C++标准委员会。提交伊始,草案就得到了委员会的初步支持,但委员会成员也对此提出了一些意见,尤其是要求斯特潘诺夫定制库内的容器,使之与底层存储模型相独立。作为对要求的回应,斯特潘诺夫发明了分配器,而正因此,标准模板库的所有容器接口也被迫重写,以与分配器相兼容。在修改标准模板库以将之引入C++标准库的过程中,许多标准委员会成员(如与比雅尼·斯特劳斯特鲁普)也与斯特潘诺夫协同工作。他们亦发现自定义分配器甚至有应用于长生命周期(持续存储)的标准模板库容器的潜力,斯特潘诺夫对此的评论则是“重要而有趣的见解”。  在原有的提案里的分配器设定中,斯特潘诺夫杂糅了一些语言特性(如可将模板参数也定义为模板),但由于当时的编译器皆无法处理之,所以最终并未被标准委员会所接纳,斯特潘诺夫则如此描述当时的情形:“比雅尼·斯特劳斯特鲁普与安迪·克尼格需要花大量时间来检查我们是否正确使用了这些未实现的特性。”在分配器应用后,之前库中直接使用的指针与也可以分配器所定义的类型替代,斯特潘诺夫亦曾如此描述分配器:“标准模板库有个不错的特性便是:唯一要提及机器相关类型的地方(......)(只需)被封装成(仅)约16行内的代码。”除此以外,斯特潘诺夫原本还打算在分配器中完全封装存储模型,但标准委员会意识到这一做法会造成无法接受的效能损失,因而为补偿之,分配器的使用需求也做了一定扩充。  分配器的应用中比较特别的一点是,容器的实现过程中可能会假定分配器对指针与相关整型的类型定义与默认分配器所提供的等价,因而给定分配器类型的所有实例在比较时常会得出“相等”的结果,而这一效果实际上恰与设计分配器的初衷背道而驰,并使带状态分配器的可用性大大受限,斯特潘诺夫后来对此评论道:“(分配器)理论上说是不差的主意(......)但不幸的是在实践中无法发挥其功效。“他洞察到若要令分配器更加实用,就有必要针对核心语言的部分进行修改。
title: 使用需求.
content: 任意满足分配器使用需求的C++类都可作分配器使用。具体来说,当一个类(在此设为类A)有为一个特定类型(在此设为类型T)的对象分配内存的能力时,该类就必须提供以下类型的定义: 如此才能以通用的方式声明对象与对该类对象的引用T。allocator提供这些指针或引用的类型定义的初衷,是隐蔽指针或引用的物理实现细节;因为在16位编程时代,"远指针"(far pointer)是与普通指针非常不同的,allocator可以定义一些结构来表示这些指针或引用,而容器类用户不需要了解其是如何实现的。  虽然按照标准,在库的实现过程中允许假定分配器(类)A的A::pointer(指针)与A::const_pointer(常量指针)即是对T*与T const*的简单的类型定义,但一般更鼓励支持通用分配器。  另外,设有对于为某一对象类型T所设定的分配器A,则A必须包含四项成员函数,分别为分配函数、解除分配函数、最大个数函数和地址函数:  除此以外,由于对象的构造/析构过程与分配/解除分配过程分别进行,因而分配器还需要成员函数A::construct(构造函数)与A::destroy(析构函数)以对对象进行构造与析构,且两者应等价于如下函数:  以上代码中使用了placement new语法,且直接调用了析构函数。  分配器应是可复制构造的,任举一例,为T类对象而设的分配器可由另一为U类所设的分配器构造。若某分配器分配了一段存储空间,则这段存储空间只能由与该分配器等价的分配器解除分配。分配器还需要提供一个模板类成员类template <typename U> struct A::rebind { typedef A<U> other; };,以模板 (C++)参数化的方式,借之来针对不同的数据类型获取不同的分配器。例如,若给定某一为整型(int)而设的分配器IntAllocator,则可执行IntAllocator::rebind<long>::other以获取对应长整型(long)的相关分配器。实际上,stl::list<int>实际要分配的是包含了双向链表指针的node<int>,而不是实际分配int类型,这是引入了rebind的初衷。  与分配器相关联的operator ==,仅当一个allocator分配的内存可以被另一个allocator释放时,上述相等比较算符返回真。operator!=的返回结果与之相反。
title: 自定义分配器.
content: 定义自定义分配器的主要原因之一是提升性能。利用专用的自定义分配器可以提高程序的效能,又或提高内存使用效率,亦或两者兼而有之。默认分配器使用new操作符分配存储空间,而这常利用C语言堆分配函数(malloc())实现。由于堆分配函数常针对偶发的内存大量分配作优化,因此在为需要一次分配大量内存的容器(如向量、双端队列)分配内存时,默认分配器一般效率良好。但是,对于与双向链表这类需要频繁分配少量内存的容器来说,若采用默认分配器分配内存,则通常效率很低。除此之外,基于malloc()的默认分配器还存在许多问题,诸如较差的引用局部性,以及可能造成。  有鉴于此,在这一情况下,人们常使用基于内存池的分配器来解决频繁少量分配问题。与默认的“按需分配”方式不同,在使用基于内存池的分配器时,程序会预先为之分配大块内存(即“内存池”),而后在需要分配内存时,自定义分配器只需向请求方返回一个指向池内内存的指针即可;而在对象析构时,并不需实际解除分配内存,而是延迟到内存池的生命周期完结时才真正解除分配。  在“自定义分配器”这一话题上,已有诸多C++专家与相关作者参与探讨,例如斯科特·梅耶斯的作品《Effective STL》与安德烈·亚历山德雷斯库的《》都有提及。梅耶斯洞察到,若要求针对某一类型T的分配器的所有实例都相等,则可移植的分配器的实例必须不包含状态。虽然C++标准鼓励库的实现者支持带状态的分配器,但梅耶斯称,相关段落是“(看似)美妙的观点”,但也几乎是空话,并称分配器的限制“过于严苛”。例如,STL的list允许splice方法,即一个list对象A的节点可以被直接移入另一个list对象B中,这就要求A的分配器申请到的内存,可被B的分配器释放掉,从而推导出A与B的分配器实例必须相等。梅耶斯的结论是,分配器最好定义为使用静态方法的类型。例如,根据C++标准,分配器必须提供一个实现了rebind方法的other类模板。  另外,在《C++程序设计语言》中,比雅尼·斯特劳斯特鲁普则认为“‘严格限制分配器,以免各对象信息不同’,这点显然问题不大”(大意),并指出大部分分配器并不需要状态,甚至没有状态情形下性能反倒更佳。他提出了三个自定义分配器的用例:内存池型的分配器、共享内存型分配器与垃圾回收型分配器,并展示了一个分配器的实现,此间利用了一个内部内存池,以快速分配/解除分配少量内存。但他也提到,如此优化可能已经在他所提供的样例分配器中实现。  自定义分配器的另一用途是调试内存相关错误。若要做到这一点,可以编写一个分配器,令之在分配时分配额外的内存,并借此存放调试信息。这类分配器不仅可以保证内存由同类分配器分配/解除分配内存,还可在一定程度上保护程序免受缓存溢出之害。
title: 使用方法.
content: 当初始化标准容器时,若需使用自定分配器,则可将其写入模板参数,以代替默认的std::allocator<T>,如下所示:  正如其他所有C++类模板般,在初始化同一标准库容器时,若使用了不同的分配器,则所生成容器的类型亦不同。譬如,若函数需一整型向量数组std::vector<int>作为参数,则其只能接受由默认分配器生成的整型向量数组。
title: C++11.
content: 通过加入“作用域”分配器,C++11标准进一步强化了分配器接口,从而保证带有嵌套式内存分配特点的容器(如字符串向量数组等)所分配到的内存皆来自容器自身的分配器。  另外,C++11标准删除了“给定类型的分配器在比较时总是相等”的模棱两可的要求,使带状态分配器不仅实用性得到提升,而且可管理进程外的共享内存。现今分配器的作用多为让程序员可以控制容器的内存分配,而非适应基底硬件的地址模型。事实上,C++11标准删去了分配器“自适应地址模型”的功能,结果抹消了其设计初衷。

Summary: 在C++编程中,分配器(英语:allocator)是C++标准库的重要组成部分。C++的库中定义了多种被统称为“容器”的数据结构(如链表、集合等),这些容器的共同特征之一,就是其大小可以在程序的运行时改变;为了实现这一点,进行动态内存分配就显得尤为必要,在此分配器就用于处理容器对内存的分配与释放请求。换句话说,分配器用于封装标准模板库(STL)容器在内存管理上的低层细节。默认情况下,C++标准库使用其自带的通用分配器,但根据具体需要,程序员也可自行定制分配器以替代之。

Allocateur (C++): En programmation C++, un allocateur () est un composant de la bibliothèque standard de C++ ("Standard Template Library" ou "STL") qui gère les demandes d'allocation et de désallocation de la mémoire.