Pourquoi n'y a-t-il pas de construction "finale" en C ++?

La gestion des exceptions en C ++ est limitée à essayer / lancer / attraper. Contrairement à Object Pascal, Java, C # et Python, même en C ++ 11, la finallyconstruction n'a pas été implémentée.

J'ai vu énormément de littérature C ++ parler de "code sécurisé d'exception". Lippman écrit que le code sécurisé d'exception est un sujet important mais complexe et complexe, qui dépasse le cadre de son introduction, ce qui semble impliquer que le code sécurisé n'est pas fondamental pour C ++. Herb Sutter consacre 10 chapitres à ce sujet dans son exceptionnel C ++!

Pourtant, il me semble que bon nombre des problèmes rencontrés lors de la tentative d'écriture de "code sécurisé d'exception" pourraient être assez bien résolus si la finallyconstruction était implémentée, permettant ainsi au programmeur de s'assurer que même en cas d'exception, le programme puisse être restauré. à un état sûr, stable, sans fuite, proche du point d’allocation des ressources et du code potentiellement problématique. En tant que programmeur Delphi et C # très expérimenté, j'utilise try .. finally, mais la plupart des programmeurs de ces langages bloquent assez largement dans mon code.

Considérant tous les "cloches et sifflets" mis en œuvre dans C ++ 11, j'ai été étonné de constater que "finalement" n'était toujours pas là.

Alors, pourquoi la finallyconstruction n'a-t-elle jamais été implémentée en C ++? Ce n'est vraiment pas un concept très difficile ou avancé à comprendre et cela aide énormément le programmeur à écrire du «code protégé par exception».

Quelques commentaires supplémentaires sur la réponse de @ Nemanja (qui, puisqu'il cite Stroustrup, est vraiment la meilleure des réponses que vous puissiez obtenir):

Il s’agit vraiment de comprendre la philosophie et les idiomes du C ++. Prenons l'exemple d'une opération qui ouvre une connexion de base de données sur une classe persistante et doit s'assurer qu'elle ferme cette connexion si une exception est levée. Ceci est une question de sécurité des exceptions et s'applique à tout langage avec des exceptions (C ++, C #, Delphi ...).

Dans une langue qui utilise try/ finally, le code pourrait ressembler à ceci:

database.Open();
try {
    database.DoRiskyOperation();
} finally {
    database.Close();
}

Simple et simple. Il y a cependant quelques inconvénients:

• Si le langage n'a pas de destructeurs déterministes, je dois toujours écrire le finallybloc, sinon je perds des ressources.
• Si DoRiskyOperationest plus qu'un appel de méthode - si j'ai un traitement à effectuer dans le trybloc - alors l' Closeopération peut finir par être un bit décent loin de l' Openopération. Je ne peux pas écrire mon nettoyage juste à côté de mon acquisition.
• Si plusieurs ressources doivent être acquises, puis libérées de manière extrêmement sûre, je peux me retrouver avec plusieurs couches de try/ finallyblocs en profondeur .

L'approche C ++ ressemblerait à ceci:

ScopedDatabaseConnection scoped_connection(database);
database.DoRiskyOperation();

Cela résout complètement tous les inconvénients de l' finallyapproche. Il présente quelques inconvénients, mais ils sont relativement mineurs:

• Vous avez de bonnes chances d’écrire ScopedDatabaseConnectionvous-même le cours. Cependant, c'est une implémentation très simple - seulement 4 ou 5 lignes de code.
• Cela implique la création d'une variable locale supplémentaire - dont vous n'êtes apparemment pas fan - d'après votre commentaire sur "la création et la destruction constantes de classes sur lesquelles s'appuyer sur leurs destructeurs pour nettoyer votre désordre est très médiocre" - mais un bon compilateur optimisera aucun des travaux supplémentaires qu’une variable locale supplémentaire implique. Une bonne conception C ++ repose beaucoup sur ces optimisations.

Personnellement, compte tenu de ces avantages et inconvénients, je trouve que la RAII est une technique bien préférable finally. Votre kilométrage peut varier.

Enfin, RAII étant un langage si bien établi en C ++, et pour soulager les développeurs de l’écriture de nombreuses Scoped...classes, il existe des bibliothèques telles que ScopeGuard et Boost.ScopeExit qui facilitent ce type de nettoyage déterministe.

De Pourquoi pas C ++ fournir une construction « enfin »? dans la FAQ sur le style et la technique C ++ de Bjarne Stroustrup :

Parce que C ++ prend en charge une alternative presque toujours meilleure: la technique "L’acquisition des ressources est une initialisation" (TC ++ PL3, section 14.4). L'idée de base est de représenter une ressource par un objet local, de sorte que le destructeur de l'objet local libère la ressource. De cette façon, le programmeur ne peut pas oublier de libérer la ressource.

La raison pour laquelle C ++ n'a pas, finallyc'est parce que cela n'est pas nécessaire en C ++. finallyest utilisé pour exécuter du code indépendamment du fait qu'une exception se soit produite ou non, ce qui est presque toujours une sorte de code de nettoyage. En C ++, ce code de nettoyage doit figurer dans le destructeur de la classe appropriée et ce destructeur sera toujours appelé, exactement comme un finallybloc. Le langage utilisé pour utiliser le destructeur lors de votre nettoyage s’appelle RAII .

Au sein de la communauté C ++, on parle peut-être davantage de code «sauf exception», mais il est presque tout aussi important dans les autres langages dotés d'exceptions. L'intérêt du code "exception sûre" est que vous réfléchissiez à l'état dans lequel se trouve votre code si une exception se produit dans l'une des fonctions / méthodes que vous appelez.
En C ++, le code 'exception safe' est légèrement plus important, car C ++ ne dispose pas d'un garbage collection qui prend en charge les objets laissés orphelins à la suite d'une exception.

La raison pour laquelle la sécurité des exceptions est davantage discutée dans la communauté C ++ provient probablement aussi du fait qu'en C ++, vous devez être plus conscient de ce qui peut mal tourner, car il existe moins de filets de sécurité par défaut dans le langage.

D'autres ont évoqué la solution RAII. C'est une très bonne solution. Mais cela ne dit pas vraiment pourquoi ils n’ont pas ajouté finallyautant car c’est une chose largement souhaitée. La réponse à cette question est plus fondamentale pour la conception et le développement de C ++: tout au long du développement de C ++, les personnes impliquées ont fermement résisté à l'introduction de fonctionnalités de conception pouvant être obtenues à l'aide d'autres fonctionnalités sans grande difficulté, en particulier lorsque cela nécessite l'introduction. de nouveaux mots-clés qui pourraient rendre l'ancien code incompatible. Comme RAII fournit une alternative très fonctionnelle à finallyet que vous pouvez réellement rouler vous-même finallyen C ++ 11, il y avait peu d’appel à faire.

Tout ce que vous avez à faire est de créer une classe Finallyqui appelle la fonction transmise à son constructeur dans son destructeur. Ensuite, vous pouvez faire ceci:

try
{
    Finally atEnd([&] () { database.close(); });

    database.doRisky();
}

En général, la plupart des programmeurs C ++ natifs préfèrent cependant les objets RAII conçus avec soin.

Vous pouvez utiliser un modèle "trap" - même si vous ne souhaitez pas utiliser le bloc try / catch.

Placez un objet simple dans la portée requise. Dans le destructeur de cet objet, mettez votre logique "finale". Quoi qu'il en soit, lorsque la pile sera déroulée, le destructeur de l'objet sera appelé et vous obtiendrez votre bonbon.

Eh bien, vous pourriez trier par vous-même finally, en utilisant Lambdas, ce qui donnerait ce qui suit pour compiler correctement (en utilisant un exemple sans RAII bien sûr, pas le plus beau morceau de code):

{
    FILE *file = fopen("test","w");

    finally close_the_file([&]{
        cout << "We're closing the file in a pseudo-finally clause." << endl;
        fclose(file);
    });
}

Voir cet article .

Je ne suis pas sûr d’être d’accord avec les affirmations que RAII est un sur-ensemble de finally. Le talon d’Achille de RAII est simple: exceptions. La RAII est implémentée avec des destructeurs, et il est toujours faux en C ++ de se débarrasser d'un destructeur. Cela signifie que vous ne pouvez pas utiliser RAII lorsque vous avez besoin de votre code de nettoyage. En finallyrevanche, si elles étaient mises en œuvre, il n’y aurait aucune raison de penser qu’il serait illégal de lancer à partir d’un finallybloc.

Considérons un chemin de code comme ceci:

void foo() {
    try {
        ... stuff ...
        complex_cleanup();
    } catch (A& a) {
        handle_a(a);
        complex_cleanup();
        throw;
    } catch (B& b) {
        handle_b(b);
        complex_cleanup();
        throw;
    } catch (...) {
        handle_generic();
        complex_cleanup();
        throw;
    }
}

Si nous avions finallynous pourrions écrire:

void foo() {
    try {
        ... stuff ...
    } catch (A& a) {
        handle_a(a);
        throw;
    } catch (B& b) {
        handle_b(b);
        throw;
    } catch (...) {
        handle_generic();
        throw;
    } finally {
        complex_cleanup();
    }
}

Mais il n’ya aucun moyen, que je puisse trouver, d’obtenir un comportement équivalent en utilisant RAII.

Si quelqu'un sait comment faire cela en C ++, la réponse m'intéresse beaucoup. Je serais même satisfait de quelque chose qui s'appuie, par exemple, sur l'application de toutes les exceptions héritées d'une même classe avec des capacités spéciales ou autres.