Bonsoir les amis,

Je suis en plein développement (jusque là, c'est normal ) et je voulais savoir si mes objets sont bien tous libérés quand je quitte mon programme (là, aussi c'est encore normal).
Pour le moment, je vérifiais juste que, à chaque TObject.Create, il y ait bien un Object.Free d'appelé.
Mais là, j'arrive à un stade où cette technique montre ces limites car:
- Mon unité commence à bien grossir: c'est un peu délicat de s'y pronener ...
- Mes objets "s'échangent" des références vers d'autres objets. Résultat: c'est pas forcément celui qui l'a crée qui le détruit.

Bon, je fais attention de tout bien libérer mais je voulais juste savoir si vous connaissiez (par hazard )  un moyen qui permet de voir s'il y a des futes de mémoires ou autres problèmes du genre.

Merci d'avance !

Si tu ne te plantes pas ......
tu ne pousseras jamais

Je l'ai téléchargé mais pas encore testé.
Ca à l'air sympa. Pourquoi ne pas le laisser en ligne histoire que toutle monde en profite ?

Merci shining, je t'avertirai une fois que je l'aurai testé (pas avant demain)

Si tu ne te plantes pas ......
tu ne pousseras jamais

"Bien que ce ne soit pas interdit, ce n'est pas une bonne méthode de programmation. Quand ça devient trop complexe, on finit par s'y perdre et ne plus savoir qui est responsable de quoi."

=> Je suis bien au courant. Mais là, pour le moment, je n'ai pas trouvé d'autre solution. Mais j'y refléchis ...
En attendant, un programme comme celui que tu m'as donné est toujours utile dna sma boite à outils.

Tu dis que c'est pas recommandé, OK. Mais quand on fait ça par exemple :

---

procedure TFrmPrinc.FormCreate(Sender: TObject);
var
  M: TMyClass;
begin
  FObjLst := TObjectList.Create(True); // OwnObjects = True;

  M := TMyClass.Create;
  M.Prop1 := 310;

  FObjLst.Add(M);
end;

procedure TFrmPrinc.FormDestroy(Sender: TObject);
begin
  FObjLst.Free;
end;

---

Là , c'est bien le cas, non ?
Allez, je lance un 'mini' débat de programmation parce que ça faisait un moment que c'était pas arrivé.

@ ++

Si tu ne te plantes pas ......
tu ne pousseras jamais

@ Delphiprog: je viens de tester ton programme.
Il est super, mais quand je ferme l'application que j'étudiais, il me dit que la RTL n'a pas fait appel à VirtualFree() ou quelque chose comme ça.
Sinon, à part ça, avant le traitement complexe, j'ai 520 pointeurs. Pendant, ça monte à dix mille (!) et après, ça redescend pile à 520. Ouf ! Pas de fuites de mémoire ?!
Mais dans le "current size" à la ligne "Pointers" la valeur ne redescend pas. Etrange ...

J'ai pas encore lu toute l'aide mais ça me parait bizarre.

@ Shining : devantla qualité dz programme MemProof, je crois que je vais laisser ta solution de côté.

Si tu ne te plantes pas ......
tu ne pousseras jamais

Okay ça fait un moment que j'avais ces codes je voulais en faire profiter les gens bien que je n'ai pas encore eu le temps de faire des tests concernant memdebug.zip voici les commenaites de l'auteur Use of it is very simple - include MemDebug.pas to first line of your project's uses clause. You will need also to enable detailed map in project/options/linker. Compile your project. Run MS WinDbg (available for free download on http://www.microsoft.com/msdn/downloads/ and select programm/open/new/ . After executing you will see string "Dumping memory leaks" and some addresses from top of stack" in form .[]. in command window of WinDbg. il faut mettre cette unité en 1er dans la clause uses !!! ce n'est pas grave car au moins on peut jetter un coup d'oeil au code source tandis que memproof n'est pas public source !!! PS : Delphiprog LOL mais bon chuis un newbie en google :p

Florenth : on ouvre un nouveau topic ou pas ?

Dans l'exemple que tu donnes, il n'y a pas de problèmes tant que le paramètre OwnsObjects est à vrai.

Ce que je voulais dire, c'est que quand tu écris une fonction qui renvoie une référence sur un objet, là il faut être très vigilant.
var
  Obj: TObject;

function CreateObject: TObject;
begin
  Result := TObject.Create;
end;

procedure Machin;
begin
  Obj := CreateObject;
end;

procedure Truc;
begin
  Obj.Name := 'Bidon';
end;

L'exemple est caricatural mais significatif. Va savoir, dans le déroulement du programme, qui est chargé de détruire la variable globale et à quel moment il faut le faire, sans compter qu'en cas de plantage du programme...  

May Delphi be with you !

---

Pensez à cliquer sur Réponse acceptée lorsque la réponse vous convient.

un coup de main grand ?

je suis assé bon pour aller depatouiller les "merdiers" dans les codes...

oublis pas aussi de faire un shema papier du genre diagrame ou tout simplement de le faire avec l'outils de delphi...
ça peut etre utile pour s'y retrouver.

@ Delphiprog : ouvrir un sujet ? Comment ça ?
Sinon, dans l'exemple que tu donnes, c'est vraiment caricatural, mais tu l'as dit. En plus, il s'agit d'une variable globale ...
Parmi toutes les sources que j'ai, je n'ai pas une seule variable globale (sauf celles des fiches gérées par Delphi bien sur). Tout le reste est dans des classes. C'est comme ça depuis que je comprend cette notion.

@ f0xi: "je suis assé bon pour aller depatouiller les "merdiers" dans les codes...". Attention, tu insinues que ton code est un merdier ... . Sinon, c'est gentil de vouloir m'aider mais je vais pas poster mon unité de 5000 lignes ici.(dont 2500 de commentaires lol)
 
"oublis pas aussi de faire un shema papier du genre diagrame ou tout simplement de le faire avec l'outils de delphi...
ça peut etre utile pour s'y retrouver."
Mais ça, je le fais déjà dans ModelMaker. Mais là, j'étais un peu coincé. Enfin ... j'ai changé quelques trucs et puis j'ai utilisé le programme que donne Delphiprog et là, ça marche.

@ +
Florent

Si tu ne te plantes pas ......
tu ne pousseras jamais