noexcept是C++中用于声明函数不抛异常的编译期机制，分为操作符和规范符两种用法；作为规范符时承诺函数绝不抛异常，否则程序终止，相比运行时检查的throw()更高效安全；常用于析构函数、移动操作和swap等需强异常安全的场景；在模板中可实现条件noexcept，在继承中派生类虚函数不得弱化基类的noexcept承诺。
noexcept运算符和异常规范在C++里，说白了，就是你给编译器一个承诺：某个函数，它保证不会抛出任何异常。这个承诺，编译器是会认真对待的，它能基于此做很多优化，也能让你的代码接口更清晰，更安全。它不像老旧的
throw()那样，只是个运行时可能被忽略的声明，
noexcept是一个编译期就能确定的属性，并且如果承诺被打破，程序会直接终止，而不是试图继续处理一个未预期的异常。
解决方案
谈到
noexcept，它其实有两种主要用途，或者说两个层面：作为操作符和作为异常规范符。
首先是作为操作符。你可以把它想象成一个编译期能计算的布尔表达式，它告诉你某个表达式（通常是函数调用）是否被声明为
noexcept。比如
noexcept(foo())，如果
foo()函数被声明为
noexcept，那这个表达式的值就是
true，否则就是
false。这在写泛型代码，尤其是模板的时候特别有用，你可以根据某个类型或函数的
noexcept属性来决定自己的模板代码是否也应该是
noexcept的。
然后，更常见也更核心的是作为异常规范符。当你写
void func() noexcept;或者
int calculate() noexcept { /* ... */ } 时，你就是在声明这个func或
calculate函数，它绝对不会抛出异常。这是一个非常强烈的契约。如果一个被声明为
noexcept的函数在执行过程中真的抛出了异常（比如它内部调用了一个可能抛异常的函数，并且那个异常没有被捕获），那么C++运行时环境不会像通常那样去查找
catch块，而是会直接调用
std::terminate()，导致程序立刻终止。这听起来有点粗暴，但实际上这是一种明确的、可预测的行为，避免了更糟糕的未定义行为，并且能让编译器在优化时大胆地不考虑异常传播的开销，比如栈展开的准备工作。
#include#include #include // 1. 作为异常规范符 void safe_function() noexcept { // 这是一个承诺，此函数不会抛出异常 std::cout << "This is a noexcept function." << std::endl; // 如果这里调用了一个可能抛异常的函数且未捕获，程序会terminate // 例如：throw std::runtime_error("Oops!"); // 会导致程序终止 } void possibly_throwing_function() { std::cout << "This function might throw." << std::endl; // throw std::runtime_error("Something went wrong!"); // 这是一个可能抛异常的函数 } // 2. 作为noexcept操作符 template void process_value(T val) noexcept(noexcept(T(val))) { // noexcept(noexcept(T(val))) // 这里的noexcept属性取决于T的构造函数是否是noexcept的 std::cout << "Processing value. Is this function noexcept? " << std::boolalpha << noexcept(process_value(val)) << std::endl; } struct MyClass { MyClass() = default; MyClass(const MyClass&) = default; // 拷贝构造函数 MyClass(MyClass&&) noexcept {} // 移动构造函数通常是noexcept的 void do_something() { std::cout << "MyClass::do_something called." << std::endl; } }; int main() { try { safe_function(); possibly_throwing_function(); // 正常调用，如果抛出会被下面的catch捕获 } catch (const std::exception& e) { std::cerr << "Caught exception: " << e.what() << std::endl; } // 使用noexcept操作符 std::cout << "Is safe_function() noexcept? " << std::boolalpha << noexcept(safe_function()) << std::endl; std::cout << "Is possibly_throwing_function() noexcept? " << std::boolalpha << noexcept(possibly_throwing_function()) << std::endl; MyClass mc; process_value(mc); // MyClass的拷贝构造不是noexcept，所以process_value(mc)也不是noexcept MyClass mc2 = std::move(mc); // 移动构造是noexcept的 return 0; }
可以看到，
noexcept是一个非常强力的工具，它在编译期就为函数行为定下了基调。
noexcept
与throw()
有什么区别？
这个问题问得特别好，因为它触及了C++异常处理机制演进的关键点。老实说，我个人觉得C++早期那个
throw()（空异常规范）真的是个历史遗留的坑，让人又爱又恨，更多是恨。
throw()是C++98/03时代的异常规范语法，比如
void func() throw();。它的本意是声明这个函数不会抛出任何异常。但问题在于，这个声明在运行时才会被检查。如果一个声明了
throw()的函数真的抛出了异常，运行时会调用
std::unexpected()，而
std::unexpected()默认又会调用
std::terminate()。听起来和
noexcept的结果一样？表面上是，但实际情况复杂得多。
首先，
throw()的运行时检查带来了性能开销，因为编译器无法完全信任这个声明，它还得保留一些异常处理的机制。更糟糕的是，
std::unexpected()的行为是可以被用户自定义的，这导致了行为的不确定性，而且在复杂的异常链中，
std::unexpected()的处理逻辑非常难以理解和调试。它更像是一个“软性”的声明，编译器往往不会因为它而做激进的优化。在C++11之后，
throw()被废弃（deprecated），C++17中更是直接移除了这个特性。
而
noexcept，它是一个编译期属性。当一个函数被标记为
noexcept时，编译器就知道了这个函数绝对不会抛出异常。如果它真的抛了，那程序就直接
std::terminate()，没得商量。这种“硬性”的保证让编译器可以进行大量的优化，比如它不需要为栈展开准备额外的元数据，也不需要考虑异常路径的开销。这对于性能敏感的代码，比如移动构造函数、析构函数等，是极其重要的。
简单来说，
throw()是“我声明我不抛，但如果你抛了，我可能会尝试做点什么（或者最终还是terminate）”，而
noexcept是“我承诺我不抛，如果我抛了，那程序就直接挂掉，别指望我能优雅处理”。
noexcept更清晰，更高效，也更符合现代C++的设计哲学——让错误尽早暴露，并且行为可预测。
何时应该使用noexcept
？
这其实是个工程决策问题，不是说所有函数都无脑加
noexcept就万事大吉。我个人觉得，使用
noexcept需要深思熟虑，因为它是一个非常强的契约。一旦你承诺了，就不能轻易打破。
最典型的应用场景，也是你几乎应该无条件考虑使用
noexcept的地方，是析构函数。一个析构函数如果抛出异常，那几乎总是灾难性的。想象一下，当一个异常正在传播，导致栈展开时，如果析构函数再抛出一个异常，那就会导致程序直接终止（
std::terminate()），因为C++标准不允许同时存在两个未处理的异常。所以，C++11之后，析构函数默认就是
noexcept的，除非你明确地让它不是（这通常是个坏主意）。
其次是移动构造函数和移动赋值运算符。比如
std::vector这样的容器，在需要重新分配内存时，如果元素的移动构造函数是
noexcept的，它就可以直接将旧内存中的元素“移动”到新内存，而不用担心移动过程中抛异常导致数据丢失或状态不一致，从而实现真正的O(1)移动。如果移动操作可能抛异常，
std::vector为了保证强异常安全，就不得不退化为拷贝操作，这会带来显著的性能开销。所以，如果你能保证你的类型移动操作不会抛异常，请务必标记为
noexcept。
再来就是交换函数（swap）。一个
swap函数通常应该保证不抛异常，因为它们经常用于实现强异常安全保证（比如copy-and-swap idiom）。如果
swap抛异常，那么很多依赖它的操作都可能无法提供强异常保证。
还有一些简单的、不会失败的工具函数或查询函数，比如纯粹的计算函数、只读的getter方法等。这些函数没有理由抛出异常，将其标记为
noexcept可以清晰地表达其意图，并可能带来微小的优化。
总的来说，当你能百分之百确定一个函数不会、也不应该抛出异常时，就勇敢地加上
noexcept。这不仅是为了性能，更是为了代码的健壮性和清晰的接口契约。如果一个函数可能抛出异常，或者你无法确定，那就不要加
noexcept，让异常正常传播。强行加上
noexcept只会让程序在意外情况下直接崩溃，而不是给你处理错误的机会。
noexcept
在模板和多态中的行为？
这部分内容其实挺有意思的，因为它涉及到
noexcept的“传染性”和继承关系，尤其是在泛型编程和面向对象设计中，这些细节就显得尤为重要。
先说模板。
noexcept操作符在模板里简直是如鱼得水。我们可以利用它来根据模板参数的
noexcept属性，来决定我们自己的模板函数是否也应该是
noexcept的。这被称为“条件
noexcept”。
例如，一个通用的
swap函数：
templatevoid my_swap(T& a, T& b) noexcept(noexcept(a.swap(b))) { // 优先调用成员swap，如果成员swap不存在，则使用std::swap using std::swap; swap(a, b); }
这里
noexcept(noexcept(a.swap(b)))表达式的意思是：如果
T类型的成员函数
swap是
noexcept的，那么
my_swap这个模板函数也是
noexcept的。如果
T没有
noexcept的成员
swap，或者根本没有成员
swap（导致
std::swap被调用，而
std::swap通常依赖于拷贝/移动构造和赋值，不一定是
noexcept的），那么
my_swap就不是
noexcept的。这种灵活性让泛型代码能够“适应”其所操作类型的异常安全属性。
再聊聊多态，也就是虚函数的情况。这里有一个很重要的规则，可以概括为“派生类的虚函数不能比基类的对应虚函数抛出更多的异常”。对于
noexcept来说，这意味着：
-
如果基类的虚函数是
noexcept
的，那么派生类重写的对应虚函数也必须是noexcept
的。你不能让一个noexcept
的基类函数，在派生类里变成一个可能抛异常的函数。这会破坏接口契约，导致编译错误。class Base { public: virtual void foo() noexcept { /* ... */ } }; class Derived : public Base { public: // virtual void foo() { /* ... */ } // 错误：不能移除noexcept virtual void foo() noexcept override { /* ... */ } // 正确 }; -
如果基类的虚函数不是
noexcept
的（即它可能抛异常），那么派生类重写的对应虚函数可以是noexcept
的，也可以不是。你可以让一个可能抛异常的基类函数，在派生类里变得更安全，承诺不抛异常。这是一种“加强”异常保证的行为，是被允许的。class Base2 { public: virtual void bar() { /* ... */ } // 可能抛异常 }; class Derived2 : public Base2 { public: virtual void bar() noexcept override { /* ... */ } // 正确：加强了保证 // 或者 virtual void bar() override { /* ... */ } // 也正确：保持和基类一样 };这个规则确保了通过基类指针或引用调用虚函数时，其异常行为不会比预期的更糟糕。当你看到一个基类接口声明了
noexcept
，你就可以放心地认为，无论实际调用的是哪个派生类实现，它都不会抛出异常。这对于设计稳定的、可预测的接口非常关键。
所以，无论是写模板还是设计类继承体系，
noexcept都扮演着一个重要的角色，它帮助我们明确地定义和传递异常安全保证，让编译器和开发者都能更好地理解和优化代码行为。
