Quand devrais-je vraiment utiliser noexcept?

Le noexceptmot-clé peut être appliqué de manière appropriée à de nombreuses signatures de fonction, mais je ne sais pas quand je devrais envisager de l'utiliser dans la pratique. Sur la base de ce que j'ai lu jusqu'à présent, l'ajout de dernière minute noexceptsemble résoudre certains problèmes importants qui surviennent lorsque les constructeurs de mouvements lancent. Cependant, je ne suis toujours pas en mesure de fournir des réponses satisfaisantes à certaines questions pratiques qui m'ont amené à en savoir plus noexcepten premier lieu.

1. Il existe de nombreux exemples de fonctions que je sais ne lanceront jamais, mais pour lesquelles le compilateur ne peut pas le déterminer par lui-même. Dois-je joindre noexceptà la déclaration de fonction dans tous ces cas?

   Devoir penser à savoir si je dois ou non ajouter noexceptaprès chaque déclaration de fonction réduirait considérablement la productivité du programmeur (et franchement, ce serait pénible). Pour quelles situations devrais-je être plus prudent quant à l'utilisation de noexcept, et pour quelles situations puis-je m'en tirer avec les implicites noexcept(false)?

2. Quand puis-je m'attendre de manière réaliste à observer une amélioration des performances après utilisation noexcept? En particulier, donnez un exemple de code pour lequel un compilateur C ++ est capable de générer un meilleur code machine après l'ajout de noexcept.

   Personnellement, je me soucie noexceptde la liberté accrue accordée au compilateur pour appliquer en toute sécurité certains types d'optimisations. Les compilateurs modernes profitent-ils de noexceptcette manière? Sinon, puis-je m'attendre à ce que certains le fassent dans un proche avenir?

Je pense qu'il est trop tôt pour donner une réponse aux "meilleures pratiques" car il n'y a pas eu assez de temps pour l'utiliser dans la pratique. Si cela était demandé à propos des lanceurs de spécification juste après leur sortie, les réponses seraient très différentes de celles d'aujourd'hui.

Devoir penser à savoir si je dois ou non ajouter noexceptaprès chaque déclaration de fonction réduirait considérablement la productivité du programmeur (et franchement, ce serait pénible).

Eh bien, utilisez-le quand il est évident que la fonction ne lancera jamais.

Quand puis-je m'attendre de manière réaliste à observer une amélioration des performances après utilisation noexcept? [...] Personnellement, je me soucie noexceptde la liberté accrue accordée au compilateur pour appliquer en toute sécurité certains types d'optimisations.

Il semble que les gains d'optimisation les plus importants proviennent des optimisations des utilisateurs et non des compilateurs en raison de la possibilité de les vérifier noexceptet de les surcharger. La plupart des compilateurs suivent une méthode de gestion des exceptions sans pénalité si vous ne lancez pas, donc je doute que cela changerait beaucoup (ou quoi que ce soit) au niveau du code machine de votre code, bien que peut-être réduire la taille binaire en supprimant le code de manipulation.

L'utilisation noexceptdans les quatre grands (constructeurs, affectations, et non destructeurs comme ils le sont déjà noexcept) entraînera probablement les meilleures améliorations car les noexceptvérifications sont «courantes» dans le code du modèle, comme dans les stdconteneurs. Par exemple, std::vectorn'utilisera pas le déplacement de votre classe à moins qu'il ne soit marqué noexcept(ou que le compilateur ne puisse le déduire autrement).

Comme je ne cesse de répéter ces jours-ci: la sémantique d'abord .

Ajouter noexcept, noexcept(true)et noexcept(false)c'est avant tout de la sémantique. Elle ne conditionne qu'incidemment un certain nombre d'optimisations possibles.

En tant que programmeur lisant du code, la présence de noexcepts'apparente à celle de const: cela m'aide à mieux comprendre ce qui peut ou non arriver. Par conséquent, il vaut la peine de passer du temps à réfléchir à savoir si vous savez si la fonction lancera. Pour rappel, tout type d'allocation dynamique de mémoire peut être lancé.

Bon, passons maintenant aux optimisations possibles.

Les optimisations les plus évidentes sont en fait effectuées dans les bibliothèques. C ++ 11 fournit un certain nombre de traits qui permettent de savoir si une fonction l'est noexceptou non, et l'implémentation de la bibliothèque standard utilisera ces traits pour favoriser les noexceptopérations sur les objets définis par l'utilisateur qu'ils manipulent, si possible. Tels que déplacer la sémantique .

Le compilateur peut seulement raser un peu de graisse (peut-être) des données de gestion des exceptions, car il doit tenir compte du fait que vous avez peut-être menti. Si une fonction marquée noexceptlance, elle std::terminateest appelée.

Cette sémantique a été choisie pour deux raisons:

• bénéficier immédiatement de noexceptmême lorsque les dépendances ne l'utilisent pas déjà (compatibilité descendante)
• permettant la spécification noexceptlors de l'appel de fonctions qui peuvent théoriquement lancer, mais ne sont pas censées le faire pour les arguments donnés

Cela fait réellement une différence (potentiellement) énorme pour l'optimiseur dans le compilateur. Les compilateurs ont en fait cette fonctionnalité depuis des années via l'instruction throw () vide après une définition de fonction, ainsi que des extensions de propriété. Je peux vous assurer que les compilateurs modernes tirent parti de ces connaissances pour générer un meilleur code.

Presque chaque optimisation dans le compilateur utilise quelque chose appelé "graphique de flux" d'une fonction pour raisonner sur ce qui est légal. Un graphe de flux se compose de ce que l'on appelle généralement des "blocs" de la fonction (zones de code qui ont une seule entrée et une seule sortie) et des bords entre les blocs pour indiquer où le flux peut aller. Noexcept modifie le graphique de flux.

Vous avez demandé un exemple précis. Considérez ce code:

void foo(int x) {
    try {
        bar();
        x = 5;
        // Other stuff which doesn't modify x, but might throw
    } catch(...) {
        // Don't modify x
    }

    baz(x); // Or other statement using x
}

Le graphique de flux de cette fonction est différent s'il barest étiqueté noexcept(il n'y a aucun moyen pour l'exécution de sauter entre la fin de barl'instruction catch). Lorsqu'il est étiqueté comme noexcept, le compilateur est certain que la valeur de x est 5 pendant la fonction baz - le bloc x = 5 est censé "dominer" le bloc baz (x) sans le bord de bar()à l'instruction catch.

Il peut alors faire quelque chose appelé "propagation constante" pour générer un code plus efficace. Ici, si baz est en ligne, les instructions utilisant x peuvent également contenir des constantes et ce qui était auparavant une évaluation d'exécution peut être transformé en une évaluation au moment de la compilation, etc.

Quoi qu'il en soit, la réponse courte: noexceptpermet au compilateur de générer un graphique de flux plus serré, et le graphique de flux est utilisé pour raisonner sur toutes sortes d'optimisations courantes du compilateur. Pour un compilateur, les annotations utilisateur de cette nature sont impressionnantes. Le compilateur essaiera de comprendre ce genre de choses, mais il ne le fait généralement pas (la fonction en question peut être dans un autre fichier objet non visible par le compilateur ou utiliser de manière transitoire une fonction qui n'est pas visible), ou quand elle le fait, il y a une exception triviale qui pourrait être levée et dont vous n'êtes même pas au courant, de sorte qu'elle ne peut pas implicitement la noexceptnommer (l'allocation de mémoire pourrait lancer bad_alloc, par exemple).

noexceptpeut considérablement améliorer les performances de certaines opérations. Cela ne se produit pas au niveau de la génération du code machine par le compilateur, mais en sélectionnant l'algorithme le plus efficace: comme d'autres l'ont mentionné, vous effectuez cette sélection en utilisant la fonction std::move_if_noexcept. Par exemple, la croissance de std::vector(par exemple, lorsque nous appelons reserve) doit fournir une forte garantie d'exception-sécurité. S'il sait que Tle constructeur de mouvement ne lance pas, il peut simplement déplacer chaque élément. Sinon, il doit copier tous Tles par. Cela a été décrit en détail dans cet article .

Quand puis-je réaliste, sauf pour observer une amélioration des performances après utilisation noexcept? En particulier, donnez un exemple de code pour lequel un compilateur C ++ est capable de générer un meilleur code machine après l'ajout de noexcept.

Euh, jamais? N'est-ce jamais un temps? Jamais.

noexceptest pour les optimisations de performances du compilateur de la même manière que constpour les optimisations de performances du compilateur. C'est presque jamais.

noexceptest principalement utilisé pour permettre à "vous" de détecter au moment de la compilation si une fonction peut lever une exception. N'oubliez pas: la plupart des compilateurs n'émettent pas de code spécial pour les exceptions à moins qu'il ne lance quelque chose. Il noexceptne s'agit donc pas de donner au compilateur des conseils sur la façon d'optimiser une fonction autant que de vous donner des conseils sur la façon d'utiliser une fonction.

Des modèles comme move_if_noexceptdétecteront si le constructeur de déplacement est défini avec noexceptet renverra un const&au lieu d'un &&du type s'il ne l'est pas. C'est une façon de dire de bouger s'il est très sûr de le faire.

En général, vous devez utiliser cette option noexceptlorsque vous pensez que cela sera réellement utile . Certains codes prendront des chemins différents si cela is_nothrow_constructibleest vrai pour ce type. Si vous utilisez du code qui le fera, n'hésitez pas à utiliser noexceptles constructeurs appropriés.

En bref: utilisez-le pour déplacer des constructeurs et des constructions similaires, mais ne vous sentez pas obligé de devenir fou avec.

Selon les mots de Bjarne ( The C ++ Programming Language, 4th Edition , page 366):

Lorsque la terminaison est une réponse acceptable, une exception non interceptée y parviendra car elle se transforme en appel de terminate () (§13.5.2.5). De plus, un noexceptspécificateur (§13.5.1.1) peut rendre ce désir explicite.

Les systèmes à tolérance de pannes réussis sont à plusieurs niveaux. Chaque niveau fait face à autant d'erreurs que possible sans être trop déformé et laisse le reste à des niveaux supérieurs. Les exceptions prennent en charge cette vue. En outre, terminate()prend en charge cette vue en fournissant un échappement si le mécanisme de gestion des exceptions lui-même est corrompu ou s'il a été utilisé de manière incomplète, laissant ainsi les exceptions non détectées. De même, noexceptfournit une échappatoire simple pour les erreurs où tenter de récupérer semble irréalisable.

double compute(double x) noexcept;     {
    string s = "Courtney and Anya";
    vector<double> tmp(10);
    // ...
}

Le constructeur vectoriel peut ne pas acquérir de mémoire pour ses dix doubles et lancer a std::bad_alloc. Dans ce cas, le programme se termine. Il se termine inconditionnellement en invoquant std::terminate()(§30.4.1.3). Il n'invoque pas de destructeurs depuis des fonctions d'appel. Il est défini par l'implémentation si les destructeurs des étendues entre le throwet le noexcept(par exemple, pour s dans compute ()) sont appelés. Le programme est sur le point de se terminer, nous ne devons donc dépendre d'aucun objet de toute façon. En ajoutant un noexceptspécificateur, nous indiquons que notre code n'a pas été écrit pour faire face à un lancer.

1. Il existe de nombreux exemples de fonctions que je sais ne lanceront jamais, mais pour lesquelles le compilateur ne peut pas le déterminer par lui-même. Dois-je ajouter noexcept à la déclaration de fonction dans tous ces cas?

noexceptest délicat, car il fait partie de l'interface des fonctions. Surtout, si vous écrivez une bibliothèque, votre code client peut dépendre de la noexceptpropriété. Il peut être difficile de le modifier plus tard, car vous pourriez casser le code existant. Cela peut être moins préoccupant lorsque vous implémentez du code uniquement utilisé par votre application.

Si vous avez une fonction qui ne peut pas être lancée, demandez-vous si elle aimera rester noexceptou cela limitera-t-il les futures implémentations? Par exemple, vous souhaiterez peut-être introduire une vérification d'erreur des arguments illégaux en lançant des exceptions (par exemple, pour les tests unitaires), ou vous pouvez dépendre d'un autre code de bibliothèque qui pourrait changer sa spécification d'exception. Dans ce cas, il est plus sûr d'être conservateur et d'omettre noexcept.

D'un autre côté, si vous êtes sûr que la fonction ne doit jamais lancer et qu'il est correct qu'elle fasse partie de la spécification, vous devez la déclarer noexcept. Cependant, gardez à l'esprit que le compilateur ne pourra pas détecter les violations de noexceptsi votre implémentation change.

2. Pour quelles situations devrais-je faire plus attention à l'utilisation de noexcept et pour quelles situations puis-je m'en tirer avec le noexcept implicite (faux)?

Il existe quatre classes de fonctions sur lesquelles vous devriez vous concentrer, car elles auront probablement le plus grand impact:

1. opérations de déplacement (opérateur d'affectation de déplacement et constructeurs de déplacement)
2. opérations de swap
3. désallocateurs de mémoire (suppression opérateur, suppression opérateur [])
4. destructeurs (bien que ceux-ci le soient implicitement noexcept(true)sauf si vous les faites noexcept(false))

Ces fonctions devraient généralement l'être noexcept, et il est très probable que les implémentations de bibliothèque puissent utiliser la noexceptpropriété. Par exemple, std::vectorpeut utiliser des opérations de déplacement sans lancer sans sacrifier les garanties d'exception fortes. Sinon, il devra se replier sur la copie des éléments (comme il l'a fait en C ++ 98).

Ce type d'optimisation est au niveau algorithmique et ne dépend pas des optimisations du compilateur. Cela peut avoir un impact significatif, surtout si les éléments sont coûteux à copier.

3. Quand puis-je m'attendre de manière réaliste à observer une amélioration des performances après avoir utilisé noexcept? En particulier, donnez un exemple de code pour lequel un compilateur C ++ est capable de générer un meilleur code machine après l'ajout de noexcept.

L'avantage de noexceptcontre aucune spécification d'exception ou throw()est que la norme permet aux compilateurs plus de liberté quand il s'agit de dérouler la pile. Même dans le throw()cas, le compilateur doit dérouler complètement la pile (et il doit le faire dans l'ordre inverse exact des constructions d'objet).

Dans le noexceptcas, en revanche, il n'est pas nécessaire de le faire. Il n'est pas nécessaire que la pile soit déroulée (mais le compilateur est toujours autorisé à le faire). Cette liberté permet une optimisation supplémentaire du code car elle réduit la surcharge de toujours pouvoir dérouler la pile.

La question connexe à propos de noexcept, du déroulement de la pile et des performances donne plus de détails sur la surcharge lorsque le déroulement de la pile est requis.

Je recommande également le livre de Scott Meyers "Effective Modern C ++", "Item 14: Declare functions noexcept if they don't emit exceptions" pour une lecture plus approfondie.

Il existe de nombreux exemples de fonctions que je sais ne lanceront jamais, mais pour lesquelles le compilateur ne peut pas le déterminer par lui-même. Dois-je ajouter noexcept à la déclaration de fonction dans tous ces cas?

Quand vous dites "je sais [qu'ils] ne lanceront jamais", vous voulez dire en examinant l'implémentation de la fonction que vous savez que la fonction ne lancera pas. Je pense que cette approche est à l'envers.

Il vaut mieux se demander si une fonction peut lever des exceptions pour faire partie de la conception de la fonction: aussi importante que la liste d'arguments et si une méthode est un mutateur (... const). Déclarer que "cette fonction ne lève jamais d'exceptions" est une contrainte sur l'implémentation. L'omettre ne signifie pas que la fonction peut lever des exceptions; cela signifie que la version actuelle de la fonction et toutes les versions futures peuvent lever des exceptions. C'est une contrainte qui rend la mise en œuvre plus difficile. Mais certaines méthodes doivent avoir la contrainte d'être pratiquement utiles; plus important encore, ils peuvent donc être appelés à partir de destructeurs, mais aussi pour la mise en œuvre de code de «roll-back» dans des méthodes qui offrent une forte garantie d'exception.