Annulation du destructeur par défaut

Question

Le code suivant ne compile pas sous gcc-4.7.1 mais compiler sous clang-3.2. Que l'on suit le standard C++11?

struct X {
  virtual ~X() = default;
};

struct Y : X {
  virtual ~Y() = default;
};

gcc-4.7.1 se plaint que:

looser throw specifier for 'virtual Y::~Y()'
error: overriding 'virtual X::~X() noexcept(true)'

Évidemment, gcc-4.7.1 pense X destructeur par défaut nothrow, mais Y destructeur par défaut n'est pas nothrow. Pourquoi est-ce? Quelqu'un peut-il se référer à la bonne place dans la norme? Merci.

J'ai vu des questions similaires sur stackoverflow, mais je n'ai pas vu les réponses se référant à la norme.

Answer 1

Les compilateurs sont pris dans un dilemme ici, pour les raisons suivantes:

(1) de ne Pas spécifier toutes les exceptions dans une déclaration de fonction (c'est à dire n'utilisant pas d' throw ni noexcept) des moyens pour permettre à cette fonction pour générer toutes les exceptions possibles:

(§15.4/12, c'est moi qui souligne) Une fonction avec aucune spécification d'exception ou avec une spécification d'exception de la forme noexcept(constant-expression) où l' constant-expression rendements en false permet toutes les exceptions. [...]

(2) Un destructeur par défaut doit permettre exactement les exceptions qui sont autorisées par les fonctions directement invoquées par sa définition implicite:

(§15.4/14, c'est moi qui souligne) Un déclarées implicitement spécial de la fonction membre (article 12) doit disposer d'une spécification d'exception. Si f est un déclarées implicitement par défaut du constructeur, constructeur de copie, déplacer constructeur, destructeur, copie opérateur d'affectation, ou de déplacer l'opérateur d'affectation, son exception implicite-cahier des charges spécifie le type-id T si et seulement si T est autorisé par la spécification d'exception d'une fonction appelée directement par f de la définition implicite; f doit permettre à toutes les exceptions si une fonction directement invoque permet toutes les exceptions, et f ne doit autoriser aucune exception si chaque fonction directement invoque permet pas d'exceptions.

(3) Lorsqu'un membre spécial (comme un destructeur) est explicitement par défaut, c'est à dire lorsque vous utilisez = default, la spécification d'exception est en option (voir l'utilisation de "peut avoir" ci-dessous):

(8.4.2/2, c'est moi qui souligne) d'Une manière explicite-par défaut de la fonction [...] peut avoir une exception explicite-spécification seulement si il est compatible (15.4) avec la spécification d'exception sur la déclaration implicite. [...]

Il n'est pas énoncé dans la Norme qui exige la spécification d'exception explicitement par défaut destructeur.

Conclusion: Donc, pas de spécifier les exceptions expressément par défaut destructeur peut être interprété de deux façons:

• Pour dire que toutes les exceptions sont autorisées (selon (1) ci-dessus)
• Ou, subsidiairement, de dire que exactement les mêmes exceptions ne sont admises que sont autorisés par l'implicite définition par défaut du destructeur (d'après (3) ci-dessus), qui, dans votre cas, d'admettre aucune exception (d'après (2) ci-dessus).

Malheureusement, GCC résout ce dilemme dans un sens (en faveur des "sans exception") dans le cas de votre base de la déclaration de classe, et d'une manière différente dans le cas de la classe dérivée (en faveur de "toutes les exceptions" - il).

Je crois que le plus naturel de l'interprétation de la présente certes ambiguë de l'est de supposer que (2) et (3) remplacer (1). La Norme ne dit pas, mais il se doit. En vertu de cette interprétation, Clang semble être ici.