Hinnant的堆栈分配器相关问题

Question

Hinnant的堆栈分配器相关问题

c++c++11memory-alignmentallocatorexception-specification

35

我一直在使用Howard Hinnant的堆栈分配器，它非常好用，但是其中的一些实现细节对我来说有点不清楚。

为什么要使用全局操作符new和delete？allocate()和deallocate()成员函数分别使用::operator new和::operator delete。类似地，成员函数construct()使用全局的placement new。为什么不允许任何用户定义的全局或类特定的重载？
为什么将对齐方式硬编码为16字节，而不是std::alignment_of<T>？
构造函数和max_size为什么要有throw()异常说明？这不被鼓励吗（例如参见More Effective C++ Item 14）？当分配器发生异常时，终止和中止是否真的必要？这是否随着新的C++11 noexcept关键字而改变？
construct()成员函数将是完美转发的理想选择（用于调用的构造函数）。这是编写符合C++11标准的分配器的方法吗？
做出其他哪些更改可以使当前代码符合C++11标准？

- TemplateRex

2

::new (p) T 保证你将构造一个 T，并且不会发生其他任何事情。如果一个类想要提供一个与通常的全局放置 new 具有相同签名的分配函数，那么它可能会做更多的事情。把 ::new (p) T 看作是一个显式的构造函数调用，而不是内存分配（后者可以被重载）。请注意，无法重载通常的全局放置 new。 - Luc Danton

@LucDanton 好的，所以如果一个类定义了自己的放置 new（例如用于记录目的），这仍然会被 ::new(p) T 调用吗？ - TemplateRex

2

至少在对齐方面，《Effective C++（第3版）》（第50项，第249页）指出：“C++要求所有operator new返回适合于任何数据类型的指针。malloc也有同样的要求。”这通常意味着16字节对齐，所以他在这方面是一致的。不知道c11和c++11是否相同，但很可能是相同的。 - BoBTFish

@BoBTFish 如果我有一个结构体，它恰好占用一个缓存行（64字节）的长度，那么如何将这样的结构体的数据对齐到64字节边界上的 std::vector 中呢？ - TemplateRex

5

补充BoBTFish的评论，可以使用alignas声明对齐的成员变量，std::aligned_storage用于对齐的自动原始存储，以及std::align用于对齐的动态分配原始存储。 - R. Martinho Fernandes

显示剩余3条评论

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Howard Hinnant · Accepted Answer

我一直在使用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()异常说明？这不是被反对的吗（例如，More Effective C++项目14）？当在分配器中发生异常时终止和中止真的必要吗？这是否随着新的C++11 noexcept关键字而改变？

这些成员永远不会抛出异常。对于C++11，我应该将它们更新为noexcept。在C++11中，装饰事物以及特殊成员变得更加重要，因为可以检测表达式是否是不抛出异常的。代码可以根据答案进行分支。已知不会抛出异常的代码更有可能导致通用代码分支到更有效的路径。在C++11中，std::move_if_noexcept是典型的例子。

永远不要使用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分配器上进行调整。但所有旋钮都有合理的默认值。

更新

我注意到我的堆栈分配器由于副本不相等而不符合规范。我决定将该分配器更新为符合C++11标准的分配器。新的分配器名为short_allocator，文档在这里。

short_allocator与堆栈分配器的区别在于，“内部”缓冲区不再是分配器的内部，而是一个单独的“arena”对象，可以位于本地堆栈、线程或静态存储期。然而，arena不是线程安全的，所以要小心。如果您想要使其线程安全，可以这样做，但效果会递减（最终您将重新发明malloc）。

这是符合要求的，因为所有分配器的副本都指向同一个外部“arena”。请注意，现在N的单位是字节，而不是T的数量。

可以通过添加C++98/03样板（typedef、构造成员、销毁成员等）将此C++11分配器转换为C++98/03分配器。这是一项繁琐但直接的任务。

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