Discussion :

[bubulemaster]

Bonjour,

j'ai chercher sur internet et sur le forum mais je n'ai rien trouvé. Quel est vraiment la différence entre la méthode Free et Destroy. De ce que j'ai compris Free libère la mémoire (par exemple ce qui a été aloué dynamiquement) et Detroy détruit l'objet et donc son emprunte mémoire. Est-ce vraiment cela ?
Avez vous un bout de code à montrer pour bien faire la différence ?

Merci d'avance.

[sofiane44]

je pense que:

destroy(objet):
si objet aloué alors libreation_mémoire
sinon erreur;

free(objet):
si objet aloué alors liberation_memoire
sinon ne fé rien;(il est déjat libéré)

[Clorish]

Non ce n'ets pas tout a fait ca
En fait c'est seulement Destroy qui est responsable de la liberation de la memoire.
C'est la seule fonction qui a une reele existance en soit.

Le probleme de Destroy, c'est quelle cherche a liberer l'objet et la memoire pointee par la reference de l'objet.

C'est a dire que ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
Obj := Nil;
Obj.Destroy;

genere une erreur car obj pointe sur "rien".

Pour eviter cela il faut faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
If Obj <> Nil Then Obj.Destroy;

Une fois qu'on a compris ca .... Ca va tout seul.
Free fait pour toi le test "If Obj <> Nil".
C'est a dire que Free verife avant de faire appel a destroy si la reference est bien valide.

[sjrd]

En fait, par habitude, on utilise toujours Free, et jamais Destroy. Jusqu'à maintenant, je suis passé par trois étapes de la compréhension du "pourquoi Free" :

1. D'abord : c'est toujours plus sûr, puisqu'on le dit ;
2. Ensuite : en fait ça sert à rien, si on code bien, on ne devrait jamais se retrouver dans une situation où on essaye de libérer nil ;
3. Maintenant : ben si, ça sert, et drôlement ! Lorsqu'une exception est déclenchée dans le constructeur d'un objet, le destructeur est immédiatement appelé ; et souvent, dans le destructeur, on libère des objets composés... Mais si l'exception est survenue avant la création de l'objet... Ben ça fait boum Et les boums pendant qu'une exception est traitée... C'est très dangereux Et pourtant ça ne relève pas du tout d'une mauvaise programmation.

[Clorish]

Je n'avais pas encore saisi le dernier point. Merci de m'en apprendre encore un peu plus

[ShaiLeTroll]

Une chose importante !

Free est une méthode normale, elle est relative au pointeur de l'objet selon un offset fixe déterminé par TObject

Destroy est une méthode virtuelle, elles est contenu dans la table des méthodes de la classe en cours !

C'est pour cela que le test à nil est possible dans le free, car l'appel à free c'est juste un appel du genre TMethod(Objet + $08); ... alors que le Destroy c'est TMethod(Objet.MethodAddress('Destroy'); et l'accès à la Table des méthodes provoque une violation d'accès si l'objet n'a pas été instancié !

[sjrd]

C'est pour cela que le test à nil est possible dans le free, car l'appel à free c'est juste un appel du genre TMethod(Objet + $08); ... alors que le Destroy c'est TMethod(Objet.MethodAddress('Destroy'); et l'accès à la Table des méthodes provoque une violation d'accès si l'objet n'a pas été instancié !

En fait c'est pas tout à fait ça (même si ça a l'effet que tu dis).

Pour Free, un appel à Obj.Free est transformé en Free(Obj), et pas Free(Obj + $08).

Pour Destroy, ce n'est pas via la table des méthodes et donc MethodAddress qu'on le récupère, mais via la VMT. Ca donne quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
MethodPtr := PPointer(Integer(Obj.ClassType) + vmtDestroy)^;
MethodPtr(Obj);

C'est donc le Obj.ClassType qui provoque une violation d'accès si Obj = nil.