[Dcmlib] Mem leak vs virtual destructor

[Benoit Regrain]

Hi,

----- Original Message ----- 
From: "Eric Boix" <Eric.Boix at creatis.insa-lyon.fr>
To: "Jean-Pierre ROUX" <jean-pierre.roux at creatis.insa-lyon.fr>
Cc: <dcmlib at tux.creatis.insa-lyon.fr>
Sent: Monday, August 02, 2004 6:21 PM
Subject: Re: [Dcmlib] Mem leak vs virtual destructor


> Salut Jean-Pierre,
>
> Quoting Jean-Pierre ROUX <jean-pierre.roux at creatis.insa-lyon.fr>:
> > En regaradant le code des DicomDir-eries, et après un large débat
> > démocratique entre Benoit et moi-même, on en était arrivés à la
> > conclusion que ce n'était rusé de dire que gdcmObject is_a
> > gdcmSQItem, mais qu'il faudra dire que gdcmObject has_a gdcmSQItem.
>
> Je me permets de rappeler que nous sommes en feature freeze. Au
> risque de paraitre rabat-joie, je recommande donc:
>  1/ de rajouter cette modification a la fin du fichier TODO,
>  2/ de passer a l'epuration de la blacklist (cf BLACK_LIST dans
>
    http://www.creatis.insa-lyon.fr/public/source/gdcm/Test/CMakeLists.txt )
>  3/ de completer ou de rendre plus paranoiaque chacune des etapes de
>     la test suite (pour ce qui est de MA parano, merci je prends mes
>     cachets tous les matins ;-),
>  3/ de regler le tres penible pb lie' a l'invocation obligatoire de
>     GetImageDataSize() avant tout appel a GetImageData(),
>  4/ enfin de regler ce qui figure deja dans le TODO...
>
> Ensuite on pourra tager, et passer a d'autres features ou modifications
> moins urgentes (diantre, j'ai decidement le sens de l'understatement)...

C'est vrai que tout ca a l'air important à faire... mais si les modif dont
parle JPR
permettent de corriger les seg fault et memory leak qu'il avait, je
considere que ca doit
rentrer dans la feature freeze. Pourquoi vouloir corriger les bug en
laissant la merde
au fond si les deux peuvent être fait d'un même coup ? (mais tant qu'on se
limite à cela)



> Enfin deux ch'tites remarques moins formelles:
> gdcmObject est apparament utilise' uniquement par les classes
> gdcmDicomDir* (par derivation).
>  1/ bien que le besoin existe sans doute, la partie DicomDir ne me semble
>     pas vraiment prioritaire et personellement je ne connais personne de
>     demandeur parmi les Creatissiens (mais bon, je suis moins solicite'
que
>     toi pour des DicomRies),

Erreur, moi j'y utilise... et oui, les fichier Dicom sont demandés dans
CardioTools et
déjà pris en compte... Donc les DicomRies sont aussi prioritaires que le
reste !


>  2/ je ne suis pas sur que gdcmObject soit un nom porteur de la "bonnne"
>     semantique,

Ca effectivement, ca peut etre changé dans une feature freeze suivante. Mais
la remarque de JPR
ne portait pas la dessus et je ne crois pas qu'il pensait le faire.


>  3/ La partie des DicomDiries est actuellement la partie la plus
legerement
>     secoue'e par la test suite:
>     * Tu as commente' out BuildUpDicomDir.cxx et makeDicomDir.cxx avec
>       comme amusant commentaire du commit:
>          "(it's useless to test unckecked code -whatever the result is-)"
>     * en premier survol, a basse altitude, TestDicomDir.cxx fait juste un
>       Print de l'unique occurence d'un DicomDir present dans GDCM_DATA.
>     Avant de faire des changements de fonds, ne serait-il pas bon
d'ameliorer
>     cette partie de la test suite ?

No comment la dessus... et oui, je n'ai pas mon mot sur tout...


> Heueu, c,a va comme bienvenue pour la reprise du boulot ?
Tu reviens bosser quand ? Eric a l'air impatient de te revoir ;-)


>    Frog, cruellement victime d'un coup de chaud (le climat sans doute ;-)
Mouaf, dans ton bocal, ce serait po plutot un coup d'froid ? ;-P lol

Benoit