为什么 std::allocator::deallocate 不是 noexcept？答案

【问题标题】：Why is std::allocator::deallocate not noexcept?为什么 std::allocator::deallocate 不是 noexcept？
【发布时间】：2018-10-24 22:06:07
【问题描述】：

C++ 规范 (ISO/IEC 14882:2011 + ISO/IEC 14882:2014) 在 Table 28 中定义 — 解除分配的分配器要求：

p 所指区域内的所有 n T 个对象都应优先销毁到这个电话。 n 应匹配传递给 allocate 以获得的值这段记忆。不抛出异常。

但为什么 deallocate 仍然 not noexcept？

【问题讨论】：

这可以说是标准中的一个缺陷，也是 gcc 和 VS 中的一个性能错误。当noexcept 函数调用另一个不是noexcept 的函数时，编译器必须添加额外的代码来调用terminate()，以防出现异常。而deallocate 的东西（比如析构函数）通常被标记为noexcept。因此，没有不必要地装饰deallocate 会导致代码膨胀。 LLVM 的 libc++ deallocate 是 noexcept。这是一个符合要求的扩展，您可以通过以下方式编写缺陷报告以使其成为必需：cplusplus.github.io/LWG/lwg-active.html#submit_issue
我认为我上面关于这是 gcc 中的性能错误的评论是不正确的。进一步的测试表明他们围绕它进行了优化。

【解决方案1】：

这是一个狭义的契约（例如，如果你传递一个不是由 allocate 返回的指针，则会导致未定义的行为），因此根据标准库的通常政策，它没有标记为 noexcept。

【讨论】：

窄合约由N3279指定：窄合约是不宽的合约。当以违反记录合同的方式调用时，函数或操作的狭窄合同会导致未定义的行为。这样的契约指定了至少一个涉及其参数、对象状态或一些外部全局状态的先决条件，例如静态对象的初始化。 vector::front() 和 vector::operator[](size_type) 是具有窄合约的标准函数的好例子。