noexcept 关键字在 c++11 中用于向编译器承诺函数不会抛出异常，尤其在移动操作中至关重要。1. 它使标准库容器如 std::vector 在扩容时优先使用高效移动而非复制操作；2. 若移动操作未标记 noexcept，容器为保证异常安全会退而求其次使用复制，影响性能；3. 移动操作若中途抛异常，可能导致资源泄漏或数据损坏，故需谨慎判断是否标记为 noexcept；4. 判断依据是函数内部所有操作是否均不抛异常，例如仅涉及原始类型移动、调用其他 noexcept 函数等；5. 若执行内存分配或调用未知函数，则不应标记 noexcept；6. 可利用 noexcept(expression) 特性实现模板类自动推导；7. 自动生成的移动操作也会根据成员/基类是否 noexcept 自动决定；8. 若标记为 noexcept 的函数实际抛异常，程序将直接调用 std::terminate 终止运行；9. 这是一种编译时契约而非运行时检查，有助于优化并简化调用者代码。
noexcept 关键字在 C++11 中，尤其是在移动操作的语境下，它主要扮演了一个“承诺”的角色。它向编译器保证，一个函数在执行过程中绝不会抛出任何异常。对于移动构造函数和移动赋值运算符来说，这个承诺至关重要，因为它直接影响了标准库容器（比如 std::vector）在进行内存重新分配时，是选择高效的移动操作，还是退而求其次地使用开销更大的复制操作，从而确保异常安全。简单来说，noexcept 让编译器和库可以放心大胆地使用移动语义，实现性能优化，同时又给出了明确的异常安全保证。
解决方案
noexcept 关键字，从我的经验来看，是 C++11 在异常安全和性能之间找到的一个精妙平衡点。它不是一个运行时检查，而是一个编译时声明。当你把一个函数标记为 noexcept，你就是在告诉编译器：“嘿，伙计，这个函数我保证它不会抛异常。” 如果这个承诺被打破了，也就是说，一个声明为 noexcept 的函数在运行时真的抛出了异常，那么程序不会像通常那样进行异常栈回溯，而是会直接调用 std::terminate，导致程序立即终止。这听起来可能有点粗暴，但很多时候，这比让一个未预期的异常在系统中四处传播，导致更复杂的未定义行为或数据损坏要好得多。
对于移动操作，noexcept 的价值尤其凸显。想象一下 std::vector 需要扩容时，它会分配一块新的更大的内存，然后把旧内存上的元素“搬”到新内存上。如果它知道元素的移动构造函数是 noexcept 的，它就可以直接使用移动操作。因为即使在搬运过程中（比如，某个元素的移动构造函数失败了），std::vector 也能保证在抛出异常时，整个容器的状态要么是旧的、有效的，要么是新的、有效的，不会出现中间的、损坏的状态。这就是所谓的“强异常安全保证”。
立即学习“C++免费学习笔记（深入）”；
但如果元素的移动构造函数没有 noexcept 保证，std::vector 就不能那么乐观了。它会担心：万一我移了一半，某个元素的移动构造函数抛异常了怎么办？我旧的内存已经释放了，新的内存还没完全填充好，那整个容器不就废了吗？为了避免这种风险，std::vector 可能会选择更保守的策略：执行复制操作。复制操作通常会先在新的内存上把所有元素都复制一份，确认所有复制都成功了，才释放旧内存。这样一来，即使复制过程中某个元素抛异常，旧的内存和数据都还在，容器依然保持有效。但代价就是，复制通常比移动慢得多，尤其对于那些资源密集型的对象。
所以，给你的移动构造函数和移动赋值运算符加上 noexcept，如果它们确实不会抛异常的话，就相当于给了标准库一个“通行证”，让它能够放心地使用最快的移动路径，从而大大提升性能。这是一种权衡，一种对你代码行为的明确声明。
为什么移动操作需要特别关注异常安全？
移动操作，在我看来，它本质上就是一种资源所有权的转移。你把一个对象内部的指针、文件句柄、网络连接这些“重型”资源，从一个对象手里迅速交接到另一个对象手里。这个过程，如果处理不当，异常安全问题就会变得非常棘手。
想想看，如果你的移动构造函数在转移资源的过程中，比如，它已经把旧对象内部的某个指针设为 nullptr 了，但是新对象在构造过程中，因为某种原因（比如内存分配失败）抛出了异常，那会发生什么？那个被设为 nullptr 的旧对象已经“交出”了资源，但新对象又没能成功“接收”它，结果就是这个资源可能永远丢失了，造成内存泄漏或者其他更严重的资源泄漏问题。这就是所谓的“部分完成”状态，一旦出现异常，整个系统就可能陷入一个难以恢复的混乱局面。
标准库容器，特别是像 std::vector 这种需要频繁进行内部数据重排（比如扩容、插入、删除）的容器，对异常安全有着非常高的要求。它们通常会努力提供“强异常安全保证”，这意味着任何操作要么完全成功，要么在失败时，容器的状态保持不变。如果移动操作不能保证不抛异常，那么为了维护这个强保证，容器就不得不放弃移动的效率，转而使用更慢但更安全的复制操作。这不仅影响性能，也使得代码的预测性变差。
所以，我们对移动操作的异常安全关注，核心就在于防止资源泄漏和数据损坏，同时又希望能够利用移动语义带来的性能优势。noexcept 就是解决这个矛盾的关键工具。
如何判断一个移动操作是否应该声明为noexcept？
这其实是个很实际的问题，我个人在写代码时也经常会琢磨。判断一个移动操作是否应该声明 noexcept，核心原则就一条：它内部执行的所有操作，是不是都保证不抛异常？
最理想的情况是，你的移动构造函数或移动赋值运算符只涉及：
-
移动原始类型或指针： 比如
int、double、char*，这些操作本身就不会抛异常。 -
调用其他已知为
noexcept的移动操作： 如果你的类成员变量是std::unique_ptr或者其他你自定义的、且你已经明确声明为noexcept的类型，那么它们的移动操作自然也不会抛异常。 -
不进行任何可能抛异常的操作： 比如不进行内存分配（
new），不调用任何可能抛异常的函数，不涉及文件 I/O 等。
如果你的移动操作完全符合上述条件，那么，毫不犹豫地给它加上 noexcept。这是对编译器和使用者的一个清晰承诺，能解锁性能优化。
那什么时候不应该加 noexcept 呢？
如果你的移动操作内部：
- 进行了内存分配（例如，你正在实现一个自定义的容器，其移动构造函数需要分配新的内部缓冲区）。
- 调用了某个你无法确定它是否会抛异常的函数（比如一个第三方库函数，或者一个用户提供的回调函数）。
- 移动了一个其自身移动操作没有声明
noexcept的成员变量。
在这些情况下，你就不应该贸然加上 noexcept。因为一旦你加了，而它又真的抛了异常，程序就会直接 std::terminate。这虽然是一种“快速失败”机制，但对于某些需要优雅处理异常的场景来说，可能并不是你想要的结果。
C++11 之后，还有一个很方便的特性叫做 noexcept(expression)。你可以用它来根据某个表达式是否 noexcept 来决定你的函数是否 noexcept。比如，一个通用的模板类，它的移动构造函数可能写成 MyClass(MyClass&& other) noexcept(noexcept(T(std::move(other.member))))，这样就非常灵活，它会根据其成员 member 的移动构造函数是否 noexcept 来自动决定自己是否 noexcept。
对于那些由编译器自动生成的（= default）移动构造函数和移动赋值运算符，它们会很智能地判断：如果所有成员和基类的移动操作都是 noexcept 的，那么它们自己也会被隐式地声明为 noexcept。这其实是个非常棒的默认行为，省去了我们很多思考。
noexcept的承诺与后果：真的不会抛异常吗？
noexcept 的承诺，说实话，它更多的是一种契约，而不是一个运行时机制。它告诉编译器：“相信我，这里绝不会有异常冒出来。” 编译器基于这个信任，会进行一些优化，比如它不需要生成处理异常栈回溯的代码，这使得 noexcept 函数的运行时开销更小。
但如果这个“承诺”被打破了呢？如果一个你声明为 noexcept 的函数，在实际运行时真的抛出了异常（比如，你内部不小心调用了一个会抛异常的函数，或者某个断言失败了），C++ 标准规定，程序会立即调用 std::terminate()。这意味着你的程序会直接崩溃，而不是像通常那样，让异常沿着调用栈向上冒泡。
为什么是 std::terminate？这背后其实有一个很实际的考量。当一个 noexcept 函数抛出异常时，这通常意味着程序进入了一个它不应该进入的状态，或者说，一个你作为程序员，根本没有预料到的错误。在这种情况下，继续执行可能会导致更严重的、难以调试的未定义行为，比如数据损坏、资源泄露，甚至安全漏洞。相比之下，直接终止程序，虽然看起来很“暴力”，但它提供了一个明确的、可预测的失败模式——“fail fast”。它告诉你：“我遇到了一个我无法处理的问题，我选择立即停止，而不是假装没事继续运行，然后可能在某个不确定的未来引发更大的灾难。”
从调用的角度来看，noexcept 也是一个非常重要的信号。如果你知道一个函数是 noexcept 的，那么你在调用它的时候，就根本不需要考虑 try-catch 块。这简化了调用者的代码，也明确了接口。它和 C++03 时代被弃用的 throw() 异常规范有着本质的区别。throw() 更多的是一种运行时检查，如果函数抛出了不在其规范列表中的异常，会调用 std::unexpected。而 noexcept 则是一种更强烈的保证，直接与 std::terminate 挂钩，并且在编译时就影响优化。
所以，当你给一个函数加上 noexcept 时，你是在郑重声明：这个函数在任何情况下都不会抛出异常。如果这个声明被打破，那么程序就无法继续正常执行，直接终止是最好的选择。这是一种强烈的契约，也是一种设计哲学。
