allocator_traits的目的是什么？在 C++0x 中？
为什么 C++0x 中没有使用标准 C++03 接口来查询分配器的成员类型？成员类型不足的用例有哪些？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为了从设计模式的角度解释 allocator_traits，它是一个 Adapter 来包装您的自定义分配器，满足的要求要少得多实现要求（不需要构造、销毁、所有这些 typedef ...）并将其转换为 FlyWeight 使用静态成员和类型为您完成分配器实现要求的其余部分的对象。
使用 allocator_traits，您只需为自定义分配器提供至少 10 行代码，如 open-std 文档第 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 间接调用自定义分配器的另一个优点是它保证向前兼容性（作用域分配器模型）。
需求的数量将来可能会增加，即使您对实施新的需求一无所知对分配器的要求，这些要求已经存在于编译器制造商实现的 allocator_traits 中。了解 C++ 容器通过 allocator_traits 间接调用分配器后，使用自定义分配器的 STL 容器将受益于新的要求，而无需您更改代码。
To explain allocator_traits in terms of design pattern, its an Adapter to wrap your custom Allocator that meets far less implementation requirement (no need for construct, destroy, all those typedefs ...) and turns it into FlyWeight object that completes the rest of the Allocator implementation requirement for you with static members and types.
With allocator_traits, you just need to provide minimum of 10 lines of code for your custom allocator, as per page 3 of open-std doc Scoped Allocator Model (thx to @icecrime for mentioning).
I think of allocator_traits and allocator as a nice real-world example of turning non-FlyWeight object into FlyWeight in order to relieve the burden of implementaion details. Its a good API design practice for turning a class into FlyWeight that should've been FlyWeight in the first place.
To Java Programmers, in terms of design pattern, std::allocator_traits is like package private classes CharacterDataLatin1, ChracterData00, CharacterData0E, 01, 02 ... that inherits from java.lang.CharacterData to provide static Unicode definition and helpers that are to be shared by every instance of Character (std::allocator) classes.
Edit:
Another advantage of indirectly calling your custom allocator through allocator_traits is that it guarantees foward compatibility (page 3 of Scoped Allocator Model).
Number of requirements may grow in the future, and even if your ignorant on implementing new requirements to your allocator, those requirements will already be there in allocator_traits implemented by the compiler manufacturer. Knowing that C++ containers call allocator indirectly by allocator_traits, the STL containers using your custom allocator will be benefiting from the new requirements without the need for you to change your code.
我对这类事情不熟悉（完全），但是此文档 似乎是了解
allocator_traits背后原理的一个很好的起点：I'm not familiar with this kind of things (at all), but this document seems like a good starting point to get a grasp on the rationale behind
allocator_traits: