¿Deberíamos proporcionar un destructor con un especificador de no-tiro?

Question

namespace QuantLib { 

    //! Base error class 
    class Error : public std::exception { 
     public: 
     /*! The explicit use of this constructor is not advised. 
      Use the QL_FAIL macro instead. 
     */ 
     Error(const std::string& file, 
       long line, 
       const std::string& functionName, 
       const std::string& message = ""); 
     /*! the automatically generated destructor would 
      not have the throw specifier. 
     */ 
     ~Error() throw() {} 
     //! returns the error message. 
     const char* what() const throw(); 
     private: 
     boost::shared_ptr<std::string> message_; 
    }; 

} 

Como puede ver a través del comentario, el destructor de la clase Error proporciona explícitamente una implementación vacía con especificador de no-tiro.

Pregunta: ¿Es esto necesario? ¿O es una buena práctica comparar para permitir que el compilador genere un destructor implícito?

Answer 1

En C++ 11, los destructores son implícitamente throw() (a menos que cualquier miembro o base del tipo tenga un destructor con una especificación de excepción diferente) por lo que si está compilando en modo C++ 11 no es necesario.

Si está en C++ 03, es posible que desee agregarlo, pero si tendrá un efecto o no, está muy definida la implementación ... Ahora, para fines de documentación, es posible que desee agregarlo, pero de nuevo , se asume comúnmente que los destructores no tiran.

Answer 2

Destructors should always be designed to never throw exceptions. Entonces, en ese sentido, no tiene sentido declarar un destructor vacío simplemente para marcarlo como no-throw.

Answer 3

Depende de lo que piense throw() medio.

Lo que realmente significa de acuerdo con la norma es "poner código adicional en cada llamada a esta función si es necesario, o en la función en sí, para asegurar que si esta función arroja la excepción se detecta y se llama std::unexpected" .

Determinados compiladores lo implementaron para indicar "optimizar las llamadas a esta función en el supuesto de que no se lanzarán", pero (en violación del estándar) no implementaron la verificación de tiempo de ejecución.

Por lo tanto, agregarlo a un destructor (que sin duda no debería tirar) a (pero en la práctica podría no) agregar una verificación de tiempo de ejecución que nunca debería activarse y, por lo tanto, podría ayudar a depurar el código. Puede o no permitir una optimización.

Answer 4

destructores siempre tienen implícitamente especificaciones de excepción:

[class.dtor] 12.4 p3

Una declaración de un destructor que no tiene una excepción de especificación se considera implícitamente a tener la misma excepción- especificación como una declaración implícita (15.4).

[except.spec] 15,4 p14

Una declarado implícitamente función miembro especial (Cláusula 12) tendrá una excepción de especificación. Si f es un constructor predeterminado declarado implícitamente, constructor de copia, mover constructor, destructor, operador de asignación de copia o operador de asignación de movimiento, su especificación de excepción implícita especifica el ID de tipo T si y solo si T está permitido por la especificación de excepción de una función invocada directamente por la definición implícita de f; f permitirá todas las excepciones si cualquier función que invoca directamente permite todas las excepciones, y f no permitirá excepciones si cada función que invoca directamente no permite excepciones.

Así que, no, no es necesario que utilice una especificación de excepción.

---

En destructores definidos por el usuario 03 C++ no tienen una especificación de excepción implícita, por lo que si lo hace definir su propio destructor no se puede confiar en el compilador para agregar automáticamente la especificación de excepción apropiado. Pero los destructores declarados implícitamente tienen la misma especificación de excepción implícita que en C++ 11.