florenth1105
Messages postés dimanche 1 août 2004Date d'inscription
17 août 2008
Dernière intervention
-
24 avril 2006 à 21:27 - Dernière réponse : cs_mounjetado69
Messages postés lundi 13 mars 2006Date d'inscription
4 août 2008
Dernière intervention
- 3 juil. 2007 à 14:19
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
"c'est pas forcément celui qui l'a crée qui le détruit"
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.
May Delphi be with you !
<HR color=#008000>
Pensez à cliquer sur Réponse acceptée lorsque la réponse vous convient.
Woot ! Je viens de tester MemCheck sur un projet et je déclare qu'il est incontournable à mon sens, et que tout débutant devrait avoir cet outil par défaut dans le source de son projet.
1- copier l'unit dans le rep du projet
2- declarer MemCheck dans les uses du .DPR
3- Toujours dans le .DPR mettre Memchk; juse apres le begin
4- regler les options debug dans "projet->options"
5- Compiler-construire....
6 - tester le prog,
et à la fermeture, si fuite il y a, notepad vous le dira.
"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 :
<hr size="2" width="100%"> 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;
<hr size ="2" width="100%">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/ <name of your exe>. After
executing you will see string "Dumping memory leaks" and some addresses from top of stack" in form .[<class name>]. 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
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 !
<HR color =#008000>
Pensez à cliquer sur Réponse acceptée lorsque la réponse vous convient.
f0xi4304
Messages postés samedi 16 octobre 2004Date d'inscription
9 mars 2018
Dernière intervention -26 avril 2006 à 00:08
0
Merci
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
f0xi4304
Messages postés samedi 16 octobre 2004Date d'inscription
9 mars 2018
Dernière intervention -27 avril 2006 à 03:59
0
Merci
hehe!
non je n'insinue pas que mon code est un merdier mais disons que je suis habituer a le faire surtout quand on faisait encore des programmes en Basic 4.0 sur TO7 ou la c'etait ... different et vraiment merdique quand a la ligne 10120 tu a un GOTO 35
sans parler du fait qu'a l'epoque ... y'avait pas d'explorateur de code pour aller plus vite ni d'ailleur de boite de recherche ou d'acces rapide aux index de lignes ... haaaaa comment faisont on pour croire que c'etait genial ce truc ...
Ben à l'époque, on ecrivait son source sur papier avant et on le déroulait à la main. Et dit toi qu'avant ca, fallait perforer des cartes, et qu'il fallait mieux oublier les fautes de syntax (sinon on se décrédibisait tres tres vite..... mdr)
Remarque, en fac en 98, quand 8 groupes de TP de fortran77 lancait leur compilation sur la vieille AIX-6000 alors que les profs faisaient tourner en background leur prog de calcul d'orbitales moléculaire (chimie quantique), soudain on sentait tout l'interet d'avoir un source clair, bien propre, n fois déroulé à la main, dument vérifié et revérifié.....
Euhh... en faisant court, ca revient à chopper la taille de la pile (du tas en fait) mémoire avant, et apres et verifier que les 2 sont égales...
Bien pratique l'instruction getHeapStatus.Totalallocated
Par contre, la gymnastique d'utilisation de Dunit, pfouyaaa c'te prise de tete, je viens de l'essayer, dans l'optique "detection fuite mémoire" sur un vieux code tout moisi de calcul par volumes finis (en 1D), v'la pas la machine à ralentir la conception....
J'prone l'usage du stylo + feuille, en ce sens qu'une fois, en deug (de sciences), un prof m'a dit :"Tu ne prends le clavier que pour recopier une fonction que tu auras écrite entierement à la main, et pour débugguer. Tes fonctions une fois tapées, tu les notes dans un cahier"
En gros : Think twice, code once.
Alors c'est peut-être pas la bonne méthode, mais je l'ai employée du deug de physique jusqu'au dea d'info, puis au taf, et ca ne m'a jamais desservi. (evidement, on note plus toutes les fonctions, procédures et autres hein, juste les gros trucs, ceux qui instancient, ceux qui dégomment, et ceux dans lesquels faut pas croiser les faisceaux paskeuh c'est Mal !)
Et quand l'idée fait pouf dans les neurones, ca permet de travailler n'importe où, bus, métro, (toilettes....), sur la plage (oh oui, c'est bon de griffoner du pseudo-code à l'ombre du parasol ) etc etc.
DUnit est un outil génial pour réaliser des tests automatisés.
Comme c'est un peu fastidieux d'écrire une batterie de tests avec, il existe un expert super bien fait : Dunit plugin for Delphi . L'essayer, c'est l'adopter
Mais ce n'est pas vraiment conçu pour la détection des fuites mémoire (Memory leaks). Des outils comme Memproof sont spécialement faits pour cela. En plus, si vous travaillez en C++, Memproof est aussi capable de placer le curseur à l'endroit du code à la source du problème !
Mais, avant d'utiliser des outils, la méthode de travail indiquée par DeltaFx est surement la meilleure : toujours réfléchir avant d'agir et non l'inverse.
Mieux encore, si vous concevez en POO, un petit diagramme de classes UML dessiné au crayon de bois sur une feuille aide à y voir clair et placer les responsabilités au bon niveau.
May Delphi be with you !
<hr color="#008000">
Pensez à cliquer sur Réponse acceptée lorsque la réponse vous convient.
bonjour j'ai lu avec beaucoup d'intérêt votre discussion car très embêté par un souci de fermeture d'application, à moins que ce ne soit un problème de fin de débogage en arrière-plan à un état stable de bureau par défaut, ce qui se traduit par l'impossibilité de relancer mon code, l'obligation de fermer et relancer delphi 2005.
bon, ceci dit 2 qst:
@DeltaFX:
4- regler les options debug dans "projet->options" : ok mais... les régler à quelle valeur?
@ DelphiProg en particulier mais qst collégiale: comment utilise-t-on DUnit sans s'embourber dans l'aide Delphi? auriez-vous un petit manuel décrivant sommairement la marche à suivre?
a aidé 91 internautes ce mois-ci