我一直在使用 Howard Hinnant 的 stack allocator，它确实有效
像一个魅力，但实施的一些细节有点
我不清楚。
很高兴它一直在为你工作。
1。为什么使用全局运算符new 和delete？ allocate() 和 deallocate() 成员函数使用 ::operator new 和
::operator delete 分别。同样，成员函数
construct() 使用全局布局 new。为什么不允许任何
用户定义的全局或特定类的重载？
没有什么特别的原因。随意以最适合您的方式修改此代码。这只是一个例子，它绝不是完美的。唯一的要求是分配器和释放器提供正确对齐的内存，并且构造成员构造一个参数。
在 C++11 中，构造（和销毁）成员是可选的。如果您在提供allocator_traits 的环境中运行，我鼓励您将它们从分配器中删除。要找出答案，只需删除它们，看看是否还能编译。
2。为什么对齐设置为硬编码的 16 字节而不是 std::alignment_of<T>？
std::alignment_of<T> 可能会正常工作。那天我可能是偏执狂。
3。为什么构造函数和max_size 有throw() 异常规范？这不是气馁吗（例如，参见更有效的 C++
第 14 项）？是否真的有必要终止和中止时
分配器中发生异常？这是否会随着新的 C++11 而改变
noexcept关键字？
这些成员永远不会扔。对于 C++11，我应该将它们更新为 noexcept。在 C++11 中，用noexcept 装饰事物变得更加重要，尤其是特殊成员。在 C++11 中，可以检测表达式是否为 nothrow。代码可以根据该答案进行分支。已知为 nothrow 的代码更有可能导致通用代码分支到更有效的路径。 std::move_if_noexcept 是 C++11 中的典型示例。
永远不要使用throw(type1, type2)。它已在 C++11 中被弃用。
当你真的想说：这永远不会抛出时，请使用throw()，如果我错了，请终止程序以便我可以调试它。 throw() 在 C++11 中也已弃用，但有一个替代品：noexcept。
4。 construct() 成员函数将是完美转发（到被调用的构造函数）的理想候选者。这是
编写符合 C++11 的分配器的方法？
是的。然而allocator_traits 会为你做这件事。让它。 std::lib 已经为您调试了该代码。 C++11 容器将调用allocator_traits<YourAllocator>::construct(your_allocator, pointer, args...)。如果你的分配器实现了这些函数，allocator_traits 将调用你的实现，否则它会调用经过调试的、高效的默认实现。
5。为了使当前代码符合 C++11，还需要进行哪些其他更改？
说实话，这个分配器并不真正符合 C++03 或 C++11。当您复制分配器时，原件和副本应该彼此相等。在这个设计中，这绝不是真的。然而，这件事在许多情况下仍然只是碰巧起作用。
如果你想让它严格符合，你需要另一个间接级别，这样副本将指向同一个缓冲区。
除此之外，C++11 分配器所以比 C++98/03 分配器更容易构建。这是您必须做的最低要求：
template <class T>
class MyAllocator
{
public:
typedef T value_type;
MyAllocator() noexcept; // only required if used
MyAllocator(const MyAllocator&) noexcept; // copies must be equal
MyAllocator(MyAllocator&&) noexcept; // not needed if copy ctor is good enough
template <class U>
MyAllocator(const MyAllocator<U>& u) noexcept; // requires: *this == MyAllocator(u)
value_type* allocate(std::size_t);
void deallocate(value_type*, std::size_t) noexcept;
};
template <class T, class U>
bool operator==(const MyAllocator<T>&, const MyAllocator<U>&) noexcept;
template <class T, class U>
bool operator!=(const MyAllocator<T>&, const MyAllocator<U>&) noexcept;
您可以选择考虑使MyAllocator 可交换并将以下嵌套类型放入分配器中：
typedef std::true_type propagate_on_container_swap;
还有一些其他类似的旋钮可以在 C++11 分配器上进行调整。但是所有的旋钮都有合理的默认值。
更新
在上面我注意到我的stack allocator 不符合，因为副本不相等。我决定将此分配器更新为符合 C++11 的分配器。新的分配器称为short_allocator，并记录在here。
short_allocator 与stack allocator 的不同之处在于“内部”缓冲区不再位于分配器内部，而是现在可以位于本地堆栈上、给定线程或静态存储时间。 arena 不是线程安全的，但请注意这一点。如果你愿意，你可以让它成为线程安全的，但这会带来收益递减（最终你会重新发明 malloc）。
这是符合要求的，因为分配器的副本都指向同一个外部arena。注意N 的单位现在是字节，而不是T 的数量。
可以通过添加 C++98/03 样板（类型定义、构造成员、销毁成员等）将此 C++11 分配器转换为 C++98/03 分配器。一项乏味但简单的任务。
对于新的short_allocator，这个问题的答案保持不变。