Os seguintesesboço, projeto do novo livro C ++ 11 de Scott Meyers (página 2, linhas 7-21)

A diferença entre desenrolar a pilha de chamadas e possivelmente desenrolá-la tem um impacto surpreendentemente grande na geração de código. Em uma função noexcept, os otimizadores não precisam manter a pilha de tempo de execução em um estado incontrolável se uma exceção se propagar para fora da função, nem devem garantir que os objetos em uma função noexcept sejam destruídos na ordem inversa da construção, se uma exceção deixar a função . O resultado são mais oportunidades de otimização, não apenas no corpo de uma função noexcept, mas também nos sites em que a função é chamada. Essa flexibilidade está presente apenas para funções noexcept. As funções com as especificações de exceção “throw ()” não possuem, assim como as funções sem nenhuma especificação de exceção.

Em contraste, a seção5.4 do"Relatório técnico sobre desempenho em C ++" descreve as formas "código" e "tabela" de implementar o tratamento de exceções. Em particular, o método "table" é mostrado como sem sobrecarga de tempo quando nenhuma exceção é lançada e possui apenas uma sobrecarga de espaço.

Minha pergunta é a seguinte: de quais otimizações Scott Meyers está falando quando fala de desanuviar vs possivelmente desanuviar? Por que essas otimizações não se aplicam athrow()? Seus comentários se aplicam apenas ao método "código" mencionado no TR de 2006?