Discussion :

[peter27x]

Hello,
j'ai trouvé ceci dans un programme :

Code :

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

1
2
3
4
5
6
 
PROCEDURE TToto.FreeObject( Item : TObject );
Begin
  Item.Free;
  Item := Nil; // Cela ne sert à rien de mettre à NIL car "Item" n'est pas un paramètre par variable
End;

Vous aurez remarqué le commentaire sur le ":= Nil".

Ma question en suivant : d'accord, mais alors dans ce cas là, le free sert il à quelque chose ?

Je suppose qu'il ne fait que libérer l'espace mémoire alloué localement à Item, mais pas l'espace mémoire de la variable manipulée par l'appelant de la procédure... Mais j'attends les avis des experts.

Merci.

[tourlourou]

Les objets sont passés par adresse [EDIT=mea culpa]=> c'est équivalent à un var Item: TObject;

mais il existe depuis Delphi 5 au moins une procedure FreeAndNil qui fait déjà ça et (je crois) ne lève pas d'exception si l'argument n'est pas assigné.

[EDIT] l'intérêt de mettre Nil, c'est de ne pas faire planter si on cherche à utiliser cet Item déjà libéré à condition de tester si bien assigné : if Assigned(Item) then Item.Execute;

[Andnotor]

Ma question en suivant : d'accord, mais alors dans ce cas là, le free sert il à quelque chose ?

Bien sûr puisque le paramètre pointe bien sur un objet existant

Les objets sont passés par adresse => c'est équivalent à un var Item: TObject;

Pas tout à fait ! Item (sans var ni const) est une copie du pointeur locale à la fonction. Affecter nil à Item n'affectera donc que sa copie.

mais il existe depuis Delphi 5 au moins une procedure FreeAndNil qui fait déjà ça et (je crois) ne lève pas d'exception si l'argument n'est pas assigné.

Free commence par faire un test sur Self <> nil avant d'appeler Destroy pour s'assurer de l'assignation du pointeur. C'est pour cela qu'il est conseillé d'appeler Free plutôt que Destroy directement. FreeAndNil cumule simplement l'appel à Free et l'assignation de nil au pointeur (passé en var ici)

[peter27x]

OK merci à vous.
Donc avec var, ce n'est pas une copie du pointeur mais le pointeur lui même qui est passé, et le nil aurait alors son intérêt. Sans var c'est une copie, mais comme elle pointe sur la même adresse mémoire que l'original, le free va aller libérer cette adresse là, donc on est bon.
Pour le freeandnil en effet c'est un programme assez ancien, ça devait pas exister à l'époque de son écriture.
Désolé, mais après plus de deux ans sans pratiquer, j'ai un peu perdu certaines bases.

[peter27x]

Quand même une remarque : en C, par exemple, un paramètre passé par adresse ou bien par valeur, c'est pas exactement comme en Delphi, c'est ça ? Le passage de paramètre Delphi est un peu particulier, non ?

[peter27x]

J'ai trouvé ceci dans un tuto Delphi du site (celui de Didier Mailliet) :

C. Paramètre donnée variable

1. définition

Il s’agit d’un passage de paramètres par valeur. On ne précède le nom du paramètre d’aucun mot (ni var, ni const ni out).
Le paramètre peut avoir une valeur avant l’appel, sa valeur peut être modifiée dans la procédure, la modification n’est pas
transmise au retour.

2. exemple

Code :

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

1
2
3
4
5
6
7
8
9
procedure essai (x,y : byte);
begin
y := x // y prend la valeur de x
end;
Var
a,b : byte:
...
a:= 3; b:= 2;
essai (a,b); // a et b conservent leurs valeurs

Ma question : si l'affectation d'une valeur à y ne s'applique pas à b, alors pourquoi, si j'ai bien compris les explications de Andnotor, le fait de faire y.free s'appliquerait à b ?

Merci.

[ShaiLeTroll]

ne confond pas un type simple comme Byte et un objet !

Si l'on repart sur ta méthode FreeObject

FreeObject appelle la méthode Free, cela invoque du code DE l'objet, il manipule directement SA mémoire
C'est le Free qui travaille sur l'objet !

FreeObject effectue une affectation d'une nouvelle valeur mais tout le code est DANS FreeObject et cela ne modifie pas l'objet mais la référence local Item sur celui-ci !

Pense à Self, sur Free ou toute méthode d'objet, il y a un paramètre invisible qui est l'objet lui-même, si l'on traduisait Free objet en un Free procédural :

Code :

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

1
2
3
4
5
procedure TObject.Free;
begin
  if Self <> nil then
    Destroy;
end;

deviendrait

Code :

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

1
2
3
4
5
procedure Free(Obj: TObject);
begin
  if Obj <> nil then
    Destroy(Obj);
end;

[Andnotor]

y.free ne s'applique pas à b, mais à la donnée pointée par b. Nuance

Modifie ton essai ainsi pour t'en convaincre :

Code :

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

1
2
3
4
5
6
7
procedure Essai(x, y :PByte);
begin
  y^ := x^; //La valeur pointée est modifiée
  y  := x;  //Le pointeur ne l'est pas
end;
 
essai(@a ,@b);

En sortie, b vaudra a.

[peter27x]

Je pense que je me suis mal fait comprendre.

Pour faire simple voici ce code simplifié :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
PROCEDURE FreeObject( Item : TObject );
Begin
  Item.Free;
end;
 
var
  b : TObject;
 
begin
  FreeObject(b);
  // est il équivalent à
  b.Free;
  // ?
end;

Ce que je cherche à savoir, c'est si depuis l'appelant, la variable b ici de type TObject passée par valeur (sémantiquement c'est ça) est affectée par le Free exécuté dans la procédure ou pas.

Car pour moi, si item est une copie de b (ce qui me semble logique) alors le item.free doit s'appliquer à item (la variable locale à la procédure), mais pas à la variable b de l'appelant.

Désolé si je vous embête avec tout ça...

Si ça vous embête pas alors coooool