Quelle est la différence conceptuelle entre finalement et un destructeur?

Tout d'abord, je sais très bien pourquoi il n'y a pas de construction «enfin» en C ++? mais une discussion de plus en plus longue sur une autre question semble justifier une question distincte.

Mis à part le problème qu'en finallyC # et Java ne peuvent essentiellement exister qu'une seule fois (== 1) par portée et qu'une seule portée peut avoir plusieurs (== n) destructeurs C ++, je pense qu'ils sont essentiellement la même chose. (Avec quelques différences techniques.)

Cependant, un autre utilisateur a fait valoir :

... J'essayais de dire qu'un dtor est intrinsèquement un outil pour (Release sematics) et finalement est intrinsèquement un outil pour (Commit semantics). Si vous ne voyez pas pourquoi: réfléchissez à la raison pour laquelle il est légitime de lancer des exceptions les unes sur les autres dans des blocs enfin, et pourquoi il n'en va pas de même pour les destructeurs. (Dans un certain sens, c'est une chose entre données et contrôle. Les destructeurs sont pour libérer des données, enfin pour libérer le contrôle. Ils sont différents; il est malheureux que C ++ les lie ensemble.)

Quelqu'un peut-il clarifier cela?

• Transaction ( try)
• Sortie / réponse d'erreur ( catch)
• Erreur externe ( throw)
• Erreur du programmeur ( assert)
• Rollback (la chose la plus proche pourrait être les gardes de portée dans les langues qui les prennent en charge nativement)
• Libération de ressources (destructeurs)
• Flux de contrôle indépendant des transactions ( finally)

Impossible de trouver une meilleure description finallyque le flux de contrôle indépendant des transactions. Il ne correspond pas nécessairement directement à un concept de haut niveau dans le contexte d'un état d'esprit de récupération de transaction et d'erreur, en particulier dans un langage théorique qui a à la fois des destructeurs et finally.

Ce qui me manque le plus intrinsèquement, c'est une fonctionnalité de langage qui représente directement le concept de réduction des effets secondaires externes. Les gardes de portée dans des langues comme D sont la chose la plus proche à laquelle je peux penser qui est proche de représenter ce concept. Du point de vue du flux de contrôle, une restauration dans la portée d'une fonction particulière devrait distinguer un chemin exceptionnel d'un chemin normal, tout en automatisant simultanément la restauration implicitement de tout effet secondaire causé par la fonction en cas d'échec de la transaction, mais pas lorsque la transaction réussit. . C'est assez facile à faire avec les destructeurs si, par exemple, nous définissons un booléen sur une valeur comme succeededtrue à la fin de notre bloc try pour empêcher la logique de restauration dans un destructeur. Mais c'est une façon plutôt détournée de le faire.

Bien que cela puisse sembler ne pas économiser autant, l'inversion des effets secondaires est l'une des choses les plus difficiles à corriger (ex: ce qui rend si difficile l'écriture d'un conteneur générique sans exception).

D'une certaine manière, ils le sont - de la même manière qu'une Ferrari et un transit peuvent tous deux être utilisés pour étouffer les magasins pour une pinte de lait, même s'ils sont conçus pour des usages différents.

Vous pouvez placer une construction try / finally dans chaque étendue et nettoyer toutes les variables définies dans l'étendue dans le bloc finally pour émuler un destructeur C ++. C'est, conceptuellement, ce que fait C ++ - le compilateur appelle automatiquement le destructeur lorsqu'une variable sort de la portée (c'est-à-dire à la fin du bloc de portée). Vous devez organiser votre essai / enfin, donc l'essai est la toute première chose et enfin la toute dernière chose dans chaque portée. Vous devez également définir une norme pour chaque objet afin d'avoir une méthode nommée spécifiquement qu'il utilise pour nettoyer son état que vous appelleriez dans le bloc finally, bien que je suppose que vous pouvez laisser la gestion de mémoire normale fournie par votre langage. nettoyez l'objet maintenant vidé quand il le souhaite.

Cependant, ce ne serait pas joli de le faire, et même si .NET a introduit IDispose en tant que destructeur géré manuellement, et en utilisant des blocs pour tenter de faciliter légèrement la gestion manuelle, ce n'est toujours pas quelque chose que vous voudriez faire dans la pratique .

De mon point de vue, la principale différence est qu'un destructeur en c ++ est un mécanisme implicite (automatiquement appelé) pour libérer les ressources allouées tandis que la tentative ... enfin peut être utilisée comme mécanisme explicite pour le faire.

Dans les programmes c ++, le programmeur est responsable de la libération des ressources allouées. Ceci est généralement implémenté dans le destructeur d'une classe et fait immédiatement lorsqu'une variable sort de la portée ou lorsque la suppression est appelée.

Quand en c ++ une variable locale d'une classe est créée sans utiliser newles ressources de ces instances sont libérées implicitement par le destructeur quand il y a une exception.

// c++
void test() {
    MyClass myClass(someParameter);
    // if there is an exception the destructor of MyClass is called automatically
    // this does not work with
    // MyClass* pMyClass = new MyClass(someParameter);

} // on test() exit the destructor of myClass is implicitly called

En java, c # et autres systèmes avec une gestion automatique de la mémoire, le garbage collector des systèmes décide quand une instance de classe est détruite.

// c#
void test() {
    MyClass myClass = new MyClass(someParameter);
    // if there is an exception myClass is NOT destroyed so there may be memory/resource leakes

    myClass.destroy(); // this is never called
}

Il n'y a pas de mécanisme implicite pour cela, vous devez donc programmer cela explicitement en utilisant try enfin

// c#
void test() {
    MyClass myClass = null;

    try {
        myClass = new MyClass(someParameter);
        ...
    } finally {
        // explicit memory management
        // even if there is an exception myClass resources are freed
        myClass.destroy();
    }

    myClass.destroy(); // this is never called
}

Heureux que vous ayez posté cette question. :)

J'essayais de dire que les destructeurs et finallysont conceptuellement différents:

• Les destructeurs servent à libérer des ressources ( données )
• finallyest pour retourner à l'appelant ( contrôle )

Considérons, disons, ce pseudo-code hypothétique:

try {
    bar();
} finally {
    logfile.print("bar has exited...");
}

finallyici résout entièrement un problème de contrôle et non un problème de gestion des ressources.
Cela n'aurait aucun sens de le faire dans un destructeur pour diverses raisons:

• Aucune chose est « acquis » ou « créé »
• Le fait de ne pas imprimer dans le fichier journal n'entraînera pas de fuites de ressources, de corruption de données, etc. (en supposant que le fichier journal ici n'est pas réinjecté ailleurs dans le programme)
• Il est légitime logfile.printd'échouer, alors que la destruction (conceptuellement) ne peut pas échouer

Voici un autre exemple, cette fois comme en Javascript:

var mo_document = document, mo;
function observe(mutations) {
    mo.disconnect();  // stop observing changes to prevent re-entrance
    try {
        /* modify stuff */
    } finally {
        mo.observe(mo_document);  // continue observing (conceptually, this can fail)
    }
}
mo = new MutationObserver(observe);
return observe();

Dans l'exemple ci-dessus, encore une fois, il n'y a aucune ressource à libérer.
En fait, le finallybloc acquiert des ressources en interne pour atteindre son objectif, ce qui pourrait potentiellement échouer. Par conséquent, il n'est pas logique d'utiliser un destructeur (si Javascript en avait un).

D'un autre côté, dans cet exemple:

b = get_data();
try {
    a.write(b);
} finally {
    free(b);
}

finallyest la destruction d' une ressource, b. C'est un problème de données. Le problème n'est pas de retourner proprement le contrôle à l'appelant, mais plutôt d'éviter les fuites de ressources.
L'échec n'est pas une option et ne devrait (conceptuellement) jamais se produire.
Chaque version de best nécessairement associée à une acquisition, et il est logique d'utiliser RAII.

En d'autres termes, simplement parce que vous pouvez utiliser soit pour simuler soit cela ne signifie pas que les deux sont un seul et même problème ou que les deux sont des solutions appropriées pour les deux problèmes.

La réponse de k3b l'exprime vraiment bien:

un destructeur en c ++ est un mécanisme implicite (invoqué automatiquement) pour libérer les ressources allouées tandis que try ... enfin peut être utilisé comme mécanisme explicite pour le faire.

Quant aux «ressources», j'aime me référer à Jon Kalb: RAII devrait signifier que l'acquisition de responsabilité est l'initialisation .

Quoi qu'il en soit, comme pour implicite vs explicite, cela semble vraiment être le cas:

• Un d'tor est un outil pour définir quelles opérations doivent se produire - implicitement - à la fin de la durée de vie d'un objet (ce qui coïncide souvent avec la fin de la portée)
• Un bloc finalement est un outil pour définir - explicitement - quelles opérations doivent se produire en fin de champ.
• De plus, techniquement, vous êtes toujours autorisé à lancer enfin, mais voir ci-dessous.

Je pense que c'est tout pour la partie conceptuelle, ...

... maintenant il y a à mon humble avis des détails intéressants:

• try / catch / enfin fait défaut car il n'y a pas de faultbloc pour exécuter du code qui ne devrait s'exécuter qu'en cas de sortie de portée exceptionnelle.
• Destructeurs peuvent être utilisés pour construire enfin des machines - voir SCOPE_EXIT, SCOPE_FAILet SCOPE_SUCCESS dans la bibliothèque de folie . Voir Andrei Alexandrescu: Gestion des erreurs dans C ++ / Flux de contrôle déclaratif (tenue au NDC 2014 )
• SCOPE_EXIT ne peut finalement se répliquer que tant, car il est techniquement parfaitement correct de lancer enfin alors qu'il ne fonctionne tout simplement pas de manière fiable à partir d'un destructeur.
• Cependant , il me semble que les gens ont tendance à penser que jeter de l'intérieur est finalement une mauvaise idée de toute façon .

Je ne pense pas non plus que le c'tor / d'tor ait besoin conceptuellement d '"acquérir" ou de "créer" quoi que ce soit, à part la responsabilité d'exécuter du code dans le destructeur. C'est ce qui fait finalement aussi: exécuter du code.

Et bien que le code dans un bloc finalement puisse certainement lever une exception, ce n'est pas assez de distinction pour moi pour dire qu'ils sont conceptuellement différents au-dessus de l'explicite et de l'implicite.

(De plus, je ne suis pas du tout convaincu que le "bon" code devrait finalement disparaître - c'est peut-être une autre question en soi.)