C'est vrai, un langage de script où il faudrait soit-même gerer ses ressources, ça manque :-).
Ce n'est pas complètement lié à la présence ou non de destructeurs, même si certains modèles de gestion mémoire se prêtent mieux au support des destructeurs qu'un garbage collector.
Le destructeur est une méthode qui est appelée lors de la désallocation de l'objet, ça n'implique pas qu'on ait à la provoquer soi-même. C'est même plus intéressant lorsqu'on a pas systématiquement à la provoquer explicitement, parce que si on en est là, il suffit juste d'appeler une méthode "finallize" avant l'appel à la désallocation, voire essayer de mettre la désallocation à la fin de cette méthode.
L'utilité des destructeurs, par exemple, c'est que si on définit une classe pour par exemple manipuler en mémoire un fichier d'état ou de préférences (c'est tout ce qui me vient comme exemple assez général tout-de-suite), le constructeur le charge, on le manipule avec les méthodes qu'on a définies, et le destructeur se charge de l'enregistrer quand on a fini.
En C++, quand on défini un objet directement (sans pointeur), il est détruit à la sortie du scope courant. Sinon, il est vrai, si on a géré l'allocation avec new, il faut gérer soi-même la destruction avec delete, mais c'est inhérent à la gestion mémoire du C++, pas au support des destructeurs.
Perl (mais il question que ça change pour la version 6) et Python, procèdent par comptage de références, c'est-à-dire que lorsqu'un objet n'est plus référencé, il est détruit. Le défaut est que ça alourdit les objets et que ça ne marche pas trop (c'est-à-dire pas du tout en l'absence de mécanisme supplémentaire) en cas de références cycliques, mais dans le cas général, ça garantit l'appel optimal des destructeurs.
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone
[^] # Re: Oui, mais...
Posté par Arthur Accroc . En réponse à la dépêche Interview de Matz le créateur de Ruby. Évalué à 3.
Ce n'est pas complètement lié à la présence ou non de destructeurs, même si certains modèles de gestion mémoire se prêtent mieux au support des destructeurs qu'un garbage collector.
Le destructeur est une méthode qui est appelée lors de la désallocation de l'objet, ça n'implique pas qu'on ait à la provoquer soi-même. C'est même plus intéressant lorsqu'on a pas systématiquement à la provoquer explicitement, parce que si on en est là, il suffit juste d'appeler une méthode "finallize" avant l'appel à la désallocation, voire essayer de mettre la désallocation à la fin de cette méthode.
L'utilité des destructeurs, par exemple, c'est que si on définit une classe pour par exemple manipuler en mémoire un fichier d'état ou de préférences (c'est tout ce qui me vient comme exemple assez général tout-de-suite), le constructeur le charge, on le manipule avec les méthodes qu'on a définies, et le destructeur se charge de l'enregistrer quand on a fini.
En C++, quand on défini un objet directement (sans pointeur), il est détruit à la sortie du scope courant. Sinon, il est vrai, si on a géré l'allocation avec new, il faut gérer soi-même la destruction avec delete, mais c'est inhérent à la gestion mémoire du C++, pas au support des destructeurs.
Perl (mais il question que ça change pour la version 6) et Python, procèdent par comptage de références, c'est-à-dire que lorsqu'un objet n'est plus référencé, il est détruit. Le défaut est que ça alourdit les objets et que ça ne marche pas trop (c'est-à-dire pas du tout en l'absence de mécanisme supplémentaire) en cas de références cycliques, mais dans le cas général, ça garantit l'appel optimal des destructeurs.
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone