c++ - 关于 Hinnant 的栈分配器的问题

Question

我一直在使用 Howard Hinnant 的 stack allocator它就像一个魅力，但实现的一些细节对我来说有点不清楚。

1. 为什么是全局运营商new和 delete用过的？ allocate()和 deallocate()成员函数使用 ::operator new和 ::operator delete分别。同样，成员函数 construct()使用全局布局 new。为什么不允许任何用户定义的全局或特定类重载？
2. 为什么对齐设置为硬编码的 16 字节而不是 std::alignment_of<T> ?
3. 为什么构造函数和max_size有一个throw()异常规范？这不气馁吗(例如，参见更有效的 C++ 第 14 条)？当分配器发生异常时，是否真的需要终止和中止？这是否会随着新的 C++11 noexcept 而改变？关键字？
4. construct()成员函数将是完美转发(到被调用的构造函数)的理想候选者。这是编写符合 C++11 的分配器的方法吗？
5. 为了使当前代码符合 C++11，还需要进行哪些其他更改？

Answer 1

I've been using Howard Hinnant's stack allocator and it works like a charm, but some details of the implementation are a little unclear to me.

很高兴它一直在为你工作。

1. Why are global operators new and delete used? The allocate() and deallocate() member functions use ::operator new and ::operator delete respectively. Similarly, the member function construct() uses the global placement new. Why not allow for any user-defined global or class-specific overloads?

没有什么特别的原因。随意以最适合您的方式修改此代码。这只是一个例子，它绝不是完美的。唯一的要求是分配器和释放器提供正确对齐的内存，并且构造成员构造一个参数。

在 C++11 中，构造(和销毁)成员是可选的。如果您在提供 allocator_traits 的环境中操作，我建议您将它们从分配器中删除。 .要找出答案，只需删除它们，看看是否还能编译。

2. Why is alignment set to hard-coded 16 bytes instead of std::alignment_of<T>?

std::alignment_of<T>可能会正常工作。那天我可能是偏执狂。

3. Why do the constructors and max_size have a throw() exception specification? Isn't this discouraged (see e.g. More Effective C++ Item 14.)? Is it really necessary to terminate and abort when an exception occurs in the allocator? Does this change with the new C++11 noexcept keyword?

这些成员永远不会扔。对于 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. The construct() member function would be an ideal candidate for perfect forwarding (to the constructor that is being called). Is this the way to write C++11 conformant allocators?

是的。然而allocator_traits会为你做的。让它。 std::lib 已经为您调试了该代码。 C++11 容器将调用 allocator_traits<YourAllocator>::construct(your_allocator, pointer, args...) .如果你的分配器实现了这些函数，allocator_traits 将调用你的实现，否则它会调用经过调试的、高效的默认实现。

5. What other changes are necessary to make the current code C++11 conformant?

说实话，这个分配器并不真正符合 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虽然不是线程安全的，但请注意这一点。如果你愿意，你可以让它成为线程安全的，但这会带来 yield 递减(最终你会重新发明 malloc)。

这是符合要求的，因为分配器的拷贝都指向同一个外部 arena .注意N的单位现在是字节，而不是 T 的数量.

可以通过添加 C++98/03 样板(typedef、构造成员、销毁成员等)将此 C++11 分配器转换为 C++98/03 分配器。一项乏味但简单的任务。

新 short_allocator 的这个问题的答案保持不变。