Why isn't standard C++03 interface for querying member types for allocators used in C++0x? What are the use cases where member types are not sufficient?
2 回答
为了从设计模式的角度来解释 allocator_traits,它是一个适配器来包装你的自定义分配器,它满足更少的实现要求(不需要构造、销毁、所有那些 typedef ......)并将其转换为完成其余部分的FlyWeight对象使用静态成员和类型对您的分配器实现要求。
使用 allocator_traits,您只需为自定义分配器提供至少 10 行代码,根据 open-std doc Scoped Allocator Model的第 3 页(感谢@icecrime 提及)。
我认为 allocator_traits 和 allocator 是一个很好的现实世界示例,将非 FlyWeight 对象转换为 FlyWeight 以减轻实现细节的负担。它是一个很好的 API 设计实践,可以将一个类变成 FlyWeight,而这本来应该是 FlyWeight。
对于 Java 程序员,就设计模式而言,std::allocator_traits 就像包私有类 CharacterDataLatin1, ChracterData00, CharacterData0E, 01, 02 ... 继承自 java.lang.CharacterData 以提供静态 Unicode 定义和要被由 Character (std::allocator) 类的每个实例共享。
编辑:通过 allocator_traits 间接调用自定义分配器的另一个优点是它保证了前向兼容性(Scoped Allocator Model的第 3 页)。未来需求的数量可能会增加,即使您不知道对分配器实现新需求,这些需求也已经存在于编译器制造商实现的 allocator_traits 中。知道 C++ 容器通过 allocator_traits 间接调用分配器,使用自定义分配器的 STL 容器将受益于新要求,而无需更改代码。
我不熟悉这类事情(完全不熟悉),但这份文档似乎是了解背后原理的一个很好的起点allocator_traits
:
该提案的基石是定义
allocator_traits
包含类型和静态成员函数以使用分配器的模板, 有效地取代Allocator
了在法兰克福丢失的概念。