C++怎么使用异常规范_C++noexcept与throw对比【安全】

noexcept是编译期断言，throw()是已弃用的运行期检查；前者允许编译器在调用点优化栈展开逻辑，后者仅在运行时抛异常才终止且c++17起被弃用，混用会导致链接失败、abi不兼容或odr违反。

noexcept 是编译期断言，throw() 是已弃用的运行期检查

你写 void f() noexcept，编译器在函数调用点就敢做优化（比如省掉栈展开逻辑）；而 void f() throw() 只在运行时抛异常才触发终止——但 C++17 起它已被标记为 deprecated，连 clang 15 都会警告。实际项目里混用两者会导致链接失败或 ABI 不兼容，尤其在跨编译单元调用时。

常见错误现象：undefined reference to 'std::unexpected()' —— 这基本是链接了旧版 libstdc++ 但用了 throw()；或者头文件声明用 noexcept，实现文件却写了 throw()，导致 ODR 违反。

• noexcept 后面可以跟常量表达式，比如 noexcept(sizeof(T) ，用于模板条件化
• throw() 不支持任何条件，只能写空括号，且无法推导
• 所有标准库容器的移动构造/赋值，仅当元素类型满足 noexcept 才启用移动语义——这点直接影响性能

什么时候必须显式写 noexcept(true/false)

不是“想加就加”。只有两类场景值得你动手：移动操作 和 析构函数。前者影响容器扩容效率（如 std::vector::push_back 是否触发拷贝），后者关系到栈展开能否安全完成。

使用场景举例：自定义类 Buffer 实现移动构造函数，内部只交换裸指针和整数成员——这天然不抛异常，但编译器不知道，必须写 Buffer(Buffer&&) noexcept，否则 std::vector<buffer></buffer> 在 realloc 时仍会走拷贝分支。

立即学习“C++免费学习笔记（深入）”；

• 析构函数默认是 noexcept(true)，但只要你在里面调了可能抛异常的函数（比如 fclose() 没检查返回值），就得显式写 ~Buffer() noexcept(false)
• 不要给普通业务函数乱加 noexcept，一旦内部调了 std::String::append 或 new，运行时抛异常直接调 std::terminate
• 模板函数慎用 noexcept，除非你能保证所有实例化路径都不抛——推荐用 noexcept(noexcept(expr)) 这种双重检查

noexcept 运算符：别在 constexpr 上栽跟头

noexcept 既是说明符，也是运算符，返回 bool 编译期常量。但它不是万能的“是否抛异常探测器”——它只看函数声明，不看函数体。

常见错误现象：写 constexpr bool can_move = noexcept(std::move(x));，结果 x 是个 std::vector，而 std::move 本身不抛，但 vector 的移动构造可能抛（比如分配器抛），这时 noexcept 运算符仍返回 true，误判。

• 正确姿势是查具体操作：比如 noexcept(T(std::declval<t>()))</t> 判断移动构造是否 noexcept
• 在 static_assert 里用它没问题，但在 if constexpr 分支里要小心——如果分支依赖 noexcept 结果，而该结果因模板参数未实例化而未被评估，可能静默失效
• noexcept 运算符对重载函数集不适用，必须明确指定函数指针或带参数类型，例如 noexcept(static_cast<void>(f))</void>

和 C 链接、ABI 兼容性有关的坑

C++ 的 noexcept 会影响函数类型，进而影响函数指针赋值和虚函数重写规则。更隐蔽的是，它还可能破坏与 C 库的 ABI 兼容性。

使用场景：你封装一个 C 接口回调函数，声明为 extern "C" void cb(void*) noexcept，但 C 头文件里对应的原型没 noexcept，GCC 会报 cannot convert 'void (*)(void*) noexcept' to 'void (*)(void*)'。

• 所有 extern "C" 函数都不能加 noexcept，C 语言没有异常概念，加了等于改类型
• 虚函数重写时，子类声明 noexcept 而父类没写，是合法的（更严格），但反过来不行——否则编译报错 override of 'virtual void f()' cannot change exception specification
• windows 下 DLL 导出函数若含 noexcept，需确认客户端编译器版本一致，否则 mangled name 可能不同，导致 GetProcAddress 失败

真正难处理的是模板 + noexcept + 导出符号组合，这时候连 __declspec(dllexport) 都可能因为 noexcept 状态不同生成不同符号。遇到链接失败，先用 dumpbin /symbols 或 nm -C 对比两边符号名是否真一致。