especificadores de excepción quedaron en desuso debido a exception specifiers are generally a terrible idea. Se agregó noexcept
porque es el uso razonablemente útil de un especificador de excepciones: saber cuándo una función no generará una excepción. Por lo tanto, se convierte en una opción binaria: funciones que lanzarán y funciones que no lanzarán.
noexcept
se ha agregado en lugar de eliminar todos los especificadores de tiro distintos de throw()
porque noexcept
es más potente. noexcept
puede tener un parámetro que el tiempo de compilación resuelve en booleano. Si boolean es verdadero, entonces el noexcept
se pega. Si boolean es falso, entonces el noexcept
no se pega y la función puede arrojar.
Por lo tanto, se puede hacer algo como esto:
struct<typename T>
{
void CreateOtherClass() { T t{}; }
};
¿El CreateOtherClass
excepciones tiro? Podría, si el constructor predeterminado de T
puede. ¿Cómo lo contamos? De esta manera:
struct<typename T>
{
void CreateOtherClass() noexcept(is_nothrow_default_constructible<T>::value) { T t{}; }
};
Por lo tanto, si y sólo si CreateOtherClass()
arrojará constructor por defecto del tipo dado lanza. Esto soluciona uno de los principales problemas con los especificadores de excepciones: su incapacidad para propagarse en la pila de llamadas.
No puede hacer esto con throw()
.
Acordar a este [buen artículo] (http://akrzemi1.wordpress.com/2011/06/10/using-noexcept/) también 'noexcept' puede incurrir en comprobaciones de tiempo de ejecución. La principal diferencia entre ellos es que romper 'noexcept' causa' std :: terminate' mientras rompe 'throw' provoca' std :: unexpected'. También un comportamiento de desenrollado de la pila ligeramente diferente en estos casos. – Fiktik