title: noexcept, stack unwinding and performance
body: <p>The following <a href="http://aristeia.com/EC++11-14/noexcept%202014-03-31.pdf" rel="noreferrer">draft</a> from Scott Meyers new C++11 book says(page 2, lines 7-21)</p>
  
  <blockquote>
    <p>The difference between unwinding the call stack and possibly unwinding it has a 
    surprisingly large impact on code generation. In a noexcept function, optimizers 
    need not keep the runtime stack in an unwindable state if an exception would 
    propagate out of the function, nor must they ensure that objects in a noexcept
    function are destroyed in the inverse order of construction should an exception 
    leave the function. The result is more opportunities for optimization, not only 
    within the body of a noexcept function, but also at sites where the function is 
    called. Such flexibility is present only for noexcept functions. Functions with 
    “throw()” exception specifications lack it, as do functions with no exception specification at all.</p>
  </blockquote>
  
  <p>In contrast, section <code>5.4</code> of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf" rel="noreferrer">"Technical Report on C++ Performance"</a> describes the "code" and "table" ways of implementing exception handling. In particular, the "table" method is shown to have no time overhead when no exceptions are thrown and only has a space overhead.</p>
  
  <p>My question is this - what optimizations is Scott Meyers talking about when he talks of unwinding vs possibly unwinding? Why don't these optimizations apply for <code>throw()</code>? Do his comments apply only to the "code" method mentioned in the 2006 TR?</p>