有“没有”开销，然后没有开销。你可以用不同的方式考虑编译器：

< li >它生成执行特定操作的程序。 < li >它生成满足特定约束的程序。

TR说在表驱动的方法中没有开销，因为只要不发生抛出，就不需要采取任何行动。非异常执行路径是直接向前的。

然而，为了使表工作，非异常代码仍然需要额外的约束。在任何异常可能导致其破坏之前，每个对象都需要完全初始化，从而限制可能引发调用的指令（例如来自内联构造函数）的重新排序。同样，在任何可能的后续异常之前，必须完全销毁对象。

基于表的展开仅适用于遵循ABI调用约定的函数和堆栈框架。如果没有异常的可能性，编译器可以忽略ABI并省略该帧。

表和单独的异常代码路径形式的空间开销（也称为膨胀）可能不会影响执行时间，但仍会影响下载程序并将其加载到RAM所需的时间。

这都是相对的，但noexcept会减少编译器的一些空闲时间。

no的区别和扔（）的区别是，在扔（）的情况下，异常堆栈仍然被解开，析构函数被调用，因此实现必须跟踪堆栈（参见15.5.2标准中的std::意外（）函数）。

相反，std:：terminate（）不要求堆栈展开（15.5.1声明，在调用td:：termnate（）之前，堆栈是否展开是由实现定义的）。

GCC 似乎真的没有解开堆栈，除了： 演示
虽然叮当仍然展开：演示

（您可以在演示中注释f_noexcept（）并取消注释f_emptythrow（），以查看GCC和clang都是如何展开堆栈的）

以以下示例为例：

#include <stdio.h>

int fun(int a) {

  int res;
  try
  {
    res = a *11;
    if(res == 33)
       throw 20;
  }
  catch (int e)
  {
    char *msg = "error";
    printf(msg);
  }
  return res;
}

int main(int argc, char** argv) {
  return fun(argc);
}

从编译器的角度来看，作为输入传递的数据是不可预见的，因此即使使用-O3优化也不能做出任何假设以完全省略调用或异常系统。

在LLVM IR中，有趣的功能大致翻译为：

define i32 @_Z3funi(i32 %a) #0 {
entry:
  %mul = mul nsw i32 %a, 11 // The actual processing
  %cmp = icmp eq i32 %mul, 33 
  br i1 %cmp, label %if.then, label %try.cont // jump if res == 33 to if.then

if.then:                                          // lots of stuff happen here..
  %exception = tail call i8* @__cxa_allocate_exception(i64 4) #3
  %0 = bitcast i8* %exception to i32*
  store i32 20, i32* %0, align 4, !tbaa !1
  invoke void @__cxa_throw(i8* %exception, i8* bitcast (i8** @_ZTIi to i8*), i8* null) #4
          to label %unreachable unwind label %lpad

lpad:                                             
  %1 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*)
          catch i8* bitcast (i8** @_ZTIi to i8*)
 ... // also here..

invoke.cont:                                      
  ... // and here
  br label %try.cont

try.cont:        // This is where the normal flow should go
  ret i32 %mul

eh.resume:                                        
  resume { i8*, i32 } %1

unreachable:                                    
  unreachable
}

如您所见，代码页，即使在正常控制流的情况下很简单（没有例外），现在也由同一个函数中的几个基本块分支组成。

的确，在运行时几乎没有成本，因为您需要为使用的内容付费（如果您不投掷，则不会发生任何额外的事情），但是拥有多个分支也可能损害您的性能，例如

< li >分支预测变得更加困难 < li >套准压力可能会大幅增加 < Li >[其他]

当然，您不能在正常控制流和着陆点/异常入口点之间运行直通分支优化。

异常是一种复杂的机制，即使在零成本 EH 中，noexcept 也极大地促进了编译器的生命周期。

编辑:在< code>noexcept说明符的特定情况下，如果编译器无法“证明”您的代码没有抛出，则会设置一个< code>std::terminate EH(带有依赖于实现的详细信息)。在这两种情况下(代码不抛出和/或不能证明代码不抛出)，涉及的机制更简单，编译器受到的约束更少。无论如何，你不会因为优化的原因而使用< code>noexcept,它也是一个重要的语义指示。