禁用异常时std::vector::shrink_to_fit()为何无效？及性能相关疑问

使用 GCC 14.2（或 Clang）编译时，禁用异常后std::vector::shrink_to_fit()不会产生效果，可通过以下代码验证：

#include <vector>
#include <iostream>

int main()
{
#ifdef __cpp_exceptions
    std::cout << "with exceptions" << '\n';
#endif

    auto v = std::vector<int>(100);
    v.resize(42);
    v.shrink_to_fit();
    std::cout << v.capacity() << '\n';  // 禁用异常时输出100，否则输出42
    {
        auto v2 = v;
        v.swap(v2);
    }
    std::cout << v.capacity() << '\n';  // 输出42
    return 0;
}

尽管std::vector::shrink_to_fit()是非绑定要求（C++标准不强制实现必须执行缩容），但禁用异常导致的行为差异仍超出预期，请问该库实现选择此逻辑的理由是什么？

额外问题：-fno-exceptions是否会导致 libstdc++ 出现其他可能影响程序性能的细微/意外差异？

一、禁用异常时shrink_to_fit()无效的原因 #

libstdc++ 中shrink_to_fit()的缩容逻辑依赖异常机制来保证强异常安全：当重新分配内存并拷贝元素时，如果中途抛出异常，容器可以回滚到原始状态，不会出现内存泄漏或无效状态。

当通过-fno-exceptions编译时，库无法依赖异常来处理拷贝失败的情况。为了避免容器陷入不可控的无效状态（比如内存分配成功但元素拷贝出错，又无法通过异常回滚），实现选择直接跳过缩容操作——毕竟缩容带来的内存收益，远小于容器状态失控带来的风险。

而代码中通过拷贝+交换的方式能成功缩容，是因为这个操作的异常安全由拷贝构造函数本身保证：如果拷贝失败，原容器不会被修改；在禁用异常的场景下，libstdc++ 假设拷贝构造函数不会失败（或失败会直接终止程序），因此该操作可以正常执行。

二、-fno-exceptions带来的其他性能相关差异 #

libstdc++ 在禁用异常时，会有不少细微的行为和性能变化，常见的包括：

• 容器操作的异常安全降级：除了vector::shrink_to_fit()，vector::reserve()、string::reserve()这类触发内存分配的操作，在禁用异常时可能放弃部分安全检查，或跳过需要异常回滚的逻辑，以此换取少量性能提升，但极端情况下可能导致容器状态异常。
• 移除异常处理代码：库内部所有try/catch块会被编译器优化掉，减少代码体积的同时，避免异常相关的分支预测开销。例如std::function、std::optional等类型的内部逻辑会去掉异常抛出路径，执行流程更简洁。
• 内存分配行为改变：operator new在禁用异常时会返回nullptr而非抛出std::bad_alloc，库容器处理分配失败时会直接终止程序（默认行为），而非尝试错误处理，这减少了相关检查代码，但也改变了错误处理逻辑。
• 算法实现路径差异：部分标准算法在禁用异常时会选择更高效但不保证异常安全的实现，比如std::sort的某些分支会跳过异常回滚逻辑，提升排序效率。

这些差异大多是为了适配无异常环境的安全需求，或通过移除异常相关代码来优化性能，但也可能带来超出预期的行为，比如原本能优雅处理的错误会直接导致程序崩溃。

内容的提问来源于stack exchange，提问作者MarkB