Discussion :

[od.ps]

Bonjour à tous,

La question a sûrement déjà été posée, mais je n'ai rien trouvé de bien clair à ce sujet.
Donc je pose ma question le plus clairement possible :

Un objet créé avec un owner à nil "

Code :

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

Toto := TTiti.Create(nil);

qui n'est pas explicitement libéré, est-il systématiquement libéré avec l'application ?

Merci d'avance.

[Andnotor]

Oui à la terminaison du processus.

[Paul TOTH]

Oui à la terminaison du processus.

plus précisément, toute la mémoire utilisée par l'application est restituée à sa fermeture, mais les destructeurs des objets ne sont pas invoqués.

[od.ps]

Ah ben au moins c'est clair .
Merci.

Donc, du coup, on peut se demander si c'est bien utile de se fatiguer à se poser la question de la libération des ressources, surtout avec les ressources d'aujourd'hui.

[Pascal Jankowski]

Justement, c'est très important de prendre soin de libérer ses ressources, car dans le cas de traitements itératifs avec instanciation de nombreuses classes, très rapidement on peut se retrouver à court de ressources.

[Paul TOTH]

Ah ben au moins c'est clair .
Merci.

Donc, du coup, on peut se demander si c'est bien utile de se fatiguer à se poser la question de la libération des ressources, surtout avec les ressources d'aujourd'hui.

ça ne me fatigue pas de concevoir des applications propres je fais parfois l'impasse sur la libération quand c'est une application console qui fait juste un traitement et se termine; exemple : un compilateur en ligne de commande, une fois qu'il a produit son objet compilé, on se fiche un peu de ce qui est en mémoire, l'application se termine de toute façon...mais ça oblige à repenser certaines parties du code quand on veux ensuite l'intégrer dans un IDE.

[od.ps]

Oui, mais les bons sentiments ont-ils une justification technique ?
A priori et à la lumière de ces précisions, je trouverais autrement plus utile que les gens "ré-apprennent" à écrire le code pascal correctement plutôt que de faire la chasse aux fuites mémoire.
Dans la plupart des sociétés que j'ai visitées , le code est écrit de façon tellement fantaisiste de la part des chefs de projet eux-mêmes , qu"il en devient illisible

[Paul TOTH]

Oui, mais les bons sentiments ont-ils une justification technique ?
A priori et à la lumière de ces précisions, je trouverais autrement plus utile que les gens "ré-apprennent" à écrire le code pascal correctement plutôt que de faire la chasse aux fuites mémoire.
Dans la plupart des sociétés que j'ai visitées , le code est écrit de façon tellement fantaisiste de la part des chefs de projet eux-mêmes , qu"il en devient illisible

un code pascal correct n'a pas de fuite mémoire

[Moez.B]

Salut,
J'ai eu l'affaire une fois à une application où les fuites mémoires sont énormes.
J'ai eu recours au FastMM pour commencer à les détecter et à corriger tout le bazard..
Après que j'ai accompli ma mission, une débutante qui commence sur la même source et rebelote ... je voulais lui expliquer que Delphi ne possède pas à vrai dire un Garbage Collector comme les technologies qu'ils ont appris au universités et facultés(Java surtout). Elle s'en fout et ça commence ...
Je rejoins l'avis de Paul, un code propre est un code qui ne génère pas de Memory Leak.. mais on a droit à l'erreur parfois ...
Ce que je conseille de le faire, c'est de contrôler toujours le cycle de vie des objets instanciés, de leur possesseurs, la manière avec laquelle on les détruit.
Si un objet se compose d'autres objets tels que les génériques (TList, TCollection..) il faut les détruire avant.
La bonne pratique c'est d'avoir recours à un destructeur redéfini dans lequel on libère les objets intermédiaires.
Bye

[e-ric]

Ah ben au moins c'est clair .
Merci.

Donc, du coup, on peut se demander si c'est bien utile de se fatiguer à se poser la question de la libération des ressources, surtout avec les ressources d'aujourd'hui.

Ceci dit, rien n'empêche de faire bien dès le départ, on ne sait jamais comment une application évolue, cela permet aussi d'entretenir les bonnes habitudes. Mais il est vrai que la gestion explicite de la mémoire est parfois "lourde".

En ce qui concerne les fuites de mémoire, si on utilise des composants externes, ce qui presque tioujours le cas, qu'est ce qui en garantit l'absence ? Je pense que ls langages à GC ne sont pas une bonne école de programmation, ils éloignent trop les développeurs du système, c'est un confort.

Delphi a conceptuellement un défaut, on ne peut pas composer réellement les objets, car c'est une sémantique de référence, ainsi, dans une liste "propriétaire" de ses objets, rien n'empêche d'en libérer un sauvagement avec un Free. La seule solution est de créer des dépendances entre les objets composants et composés. Dans maints projets que j'ai repris, les pisseurs de lignes (j'appelle pas cela des développeurs) n'avaient pas le moindre égard pour ces "détails", je me demande même s'il comprenaient réellement la notion de composition.

@+

[Moez.B]

Ceci dit, rien n'empêche de faire bien dès le départ, on ne sait jamais comment une application évolue, cela permet aussi d'entretenir les bonnes habitudes. Mais il est vrai que la gestion explicite de la mémoire est parfois "lourde".

En ce qui concerne les fuites de mémoire, si on utilise des composants externes, ce qui presque tioujours le cas, qu'est ce qui en garantit l'absence ? Je pense que ls langages à GC ne sont pas une bonne école de programmation, ils éloignent trop les développeurs du système, c'est un confort.

Delphi a conceptuellement un défaut, on ne peut pas composer réellement les objets, car c'est une sémantique de référence, ainsi, dans une liste "propriétaire" de ses objets, rien n'empêche d'en libérer un sauvagement avec un Free. La seule solution est de créer des dépendances entre les objets composants et composés. Dans maints projets que j'ai repris, les pisseurs de lignes (j'appelle pas cela des développeurs) n'avaient pas le moindre égard pour ces "détails", je me demande même s'il comprenaient réellement la notion de composition.

@+

Clairement expliqué par @e-ric, je mentionne que les développeurs d'aujourd'hui s'en prennent très mal par rapport à l'allocation de la mémoire, quand est ce qu'il faut allouer , combien ( size, capacity ..) quand est ce qu'il faut la détruire.
La notion des pointeurs est leur utilisation est très floue pour eux (Pourquoi et comment les utiliser et dans quel contexte) , la manière avec laquelle il faut gérer la notion des dépendances et des compositions
Je rejoins toujours l'avis de @ShaiLeTroll (notre cher membre remarquable) que nous apprenons toujours de lui, que les néo-développeurs ne savent pas utiliser correctement Delphi. Il a une palette surchargée de composants tiers qu'il utilise sans comprendre c'est quoi un composant... Je suis passé par là une fois et maintenant, je relance ma carrière en Delphi dans une grande boîte confrontée à des développeurs à l'ancienne avec eux j'ai fait beaucoup de remises en question à propos de ces sujets.

[e-ric]

Je dirai que l'approche par composant, bien que progrès indéniable, donne une impression trompeuse de facilité. Les nouveaux développeurs sont peut-être dérouté par les efforts demandés dans un environnement qui se prétend RAD.

La notion des pointeurs est leur utilisation est très floue pour eux (Pourquoi et comment les utiliser et dans quel contexte) , la manière avec laquelle il faut gérer la notion des dépendances et des compositions

Tous ne sont pas comme cela mais pour les autres c'est choquant, car ils ont en général une formation OO, où la notion de compostion est fondamentale.

Je rejoins toujours l'avis de @ShaiLeTroll (notre cher membre remarquable) que nous apprenons toujours de lui, que les néo-développeurs ne savent pas utiliser correctement Delphi. Il a une palette surchargée de composants tiers qu'il utilise sans comprendre c'est quoi un composant...

Les composants c'est bien, mais le plus souvent mes classes utilitaires n'en sont pas, sinon il faut les intégrer dans l'IDE et ça m'ennuie...

[Moez.B]

Les composants c'est bien, mais le plus souvent mes classes utilitaires n'en sont pas, sinon il faut les intégrer dans l'IDE et ça m'ennuie...

Dans le projet actuel sur lequel je bosse, il y a intégration des classes utilitaires dans les composants tiers (Jedy, Orpheus..). Exemple: un TEdit de DevExpress servant à un objet de saisie pour un objet métier et tout le traitement derrière.
Mais je reviens sur la POO, c'est vrai, on a tous appris la POO mais je crois que çe ne sont que des concepts. Apprendre POO c'est facile, la pratiquer c'est difficile. Créer un modèle avec un patron de conception générique doit passer par les Design Patterns: les connaître c'est facile, les mettre dans le terrain: c'est ça l'enjeu.

[jeromelef2]

Salut,
J'ai eu l'affaire une fois à une application où les fuites mémoires sont énormes.
J'ai eu recours au FastMM pour commencer à les détecter et à corriger tout le bazard..
Après que j'ai accompli ma mission, une débutante qui commence sur la même source et rebelote ... je voulais lui expliquer que Delphi ne possède pas à vrai dire un Garbage Collector comme les technologies qu'ils ont appris au universités et facultés(Java surtout). Elle s'en fout et ça commence ...
Je rejoins l'avis de Paul, un code propre est un code qui ne génère pas de Memory Leak.. mais on a droit à l'erreur parfois ...
Ce que je conseille de le faire, c'est de contrôler toujours le cycle de vie des objets instanciés, de leur possesseurs, la manière avec laquelle on les détruit.
Si un objet se compose d'autres objets tels que les génériques (TList, TCollection..) il faut les détruire avant.
La bonne pratique c'est d'avoir recours à un destructeur redéfini dans lequel on libère les objets intermédiaires.
Bye

bonjour,
voici mon avis personnel avec mon expérience:
les "développeurs" qui font comme le stagiaire ci dessus n'ont fait que de l'informatique de gestion. si l'application plante, ce n'est pas grave, il y a un utilisateur derrière pour redémarrer, et ça peut importe la distance entre le bureau de dev et l'utilisateur.

dans le cas ou le dev vient du domaine industriel ( comme moi ), je faisais des applications qui devaient tourner 24/24 7/7, sur un serveur sans clavier/souris, avec accès très restreint et il était hors de question de se déplacer à l'autre bout de la france pour redémarrer l'application, ..., donc il faut faire très attention au memoryleak, ....
ensuite, le faite de bosser avec des machines, ou faire des logiciels de traitements en masse, la qualité du code est importante. il faut faire du code optimisé pour éviter de rater des événements venant de la machine, ou de faire attendre un utilisateur.

après, li y a aussi le type de diffusion : logiciel interne ou logiciel vendu. certains ne font pas d'effort lorsqu'il s'agit d'un logiciel interne

[Moez.B]

bonjour,
voici mon avis personnel avec mon expérience:
les "développeurs" qui font comme le stagiaire ci dessus n'ont fait que de l'informatique de gestion. si l'application plante, ce n'est pas grave, il y a un utilisateur derrière pour redémarrer, et ça peut importe la distance entre le bureau de dev et l'utilisateur.

dans le cas ou le dev vient du domaine industriel ( comme moi ), je faisais des applications qui devaient tourner 24/24 7/7, sur un serveur sans clavier/souris, avec accès très restreint et il était hors de question de se déplacer à l'autre bout de la france pour redémarrer l'application, ..., donc il faut faire très attention au memoryleak, ....
ensuite, le faite de bosser avec des machines, ou faire des logiciels de traitements en masse, la qualité du code est importante. il faut faire du code optimisé pour éviter de rater des événements venant de la machine, ou de faire attendre un utilisateur.

après, li y a aussi le type de diffusion : logiciel interne ou logiciel vendu. certains ne font pas d'effort lorsqu'il s'agit d'un logiciel interne

Je crois qu'un code propre doit possèder les normes suivantes:
- Code court et simpliste réalisant à la fois l'objectif de la tâche demandée.
- Code où on contrôle la mémoire.
- Code réutilisable, commenté pour d'éventuelles évolutions.
- Code maintenable.
- Code Testable surtout ( voici un lien comme exemple pour écrire un code testable :http://robstechcorner.blogspot.com/2...interface.html )
Mais, comme tu as mentionné, être attentionné aux applications des clients et laisser des fautes dans le code interne pour des solutions internes à la boîte ou à la société est un fait amusant des développeurs qui se lassent parfois et devrait faire face à cette situation : faire du n'importe quoi

[Rayek]

bonjour,
voici mon avis personnel avec mon expérience:
les "développeurs" qui font comme le stagiaire ci dessus n'ont fait que de l'informatique de gestion. si l'application plante, ce n'est pas grave, il y a un utilisateur derrière pour redémarrer, et ça peut importe la distance entre le bureau de dev et l'utilisateur.

dans le cas ou le dev vient du domaine industriel ( comme moi ), je faisais des applications qui devaient tourner 24/24 7/7, sur un serveur sans clavier/souris, avec accès très restreint et il était hors de question de se déplacer à l'autre bout de la france pour redémarrer l'application, ..., donc il faut faire très attention au memoryleak, ....
ensuite, le faite de bosser avec des machines, ou faire des logiciels de traitements en masse, la qualité du code est importante. il faut faire du code optimisé pour éviter de rater des événements venant de la machine, ou de faire attendre un utilisateur.

après, li y a aussi le type de diffusion : logiciel interne ou logiciel vendu. certains ne font pas d'effort lorsqu'il s'agit d'un logiciel interne

C'est quoi ces préjugés sur les développeurs en informatique de gestion
Je fais aussi des logiciels qui doivent tourner 24/24 7/7.
De plus on essai que les logiciels de gestion ne plantent pas dans les pattes du clients.