[Dcmlib] TestMakeIcon : exit dans gdcmDocument]

[Benoit Regrain]

Une petite remarque sur le C++ et le new...
Voici la bonne facon, propre et standard d'utiliser le C++,
mais que personne ne fait... meme pas moi...

Au new est associé un _new_handler qui est un pointeur sur
une fonction définissable par la méthode set_new_handler(...).
Cette méthode, lorsqu'elle est définie, est appelée lors de
l'allocation de mémoire si cette allocation n'a pu se faire.

Benoit

----- Original Message ----- 
From: "Mathieu Malaterre" <mathieu.malaterre at kitware.com>
To: "Jean-Pierre ROUX" <jean-pierre.roux at creatis.insa-lyon.fr>
Cc: <dcmlib at creatis.univ-lyon1.fr>
Sent: Tuesday, April 26, 2005 12:23 AM
Subject: Re: [Dcmlib] TestMakeIcon : exit dans gdcmDocument]


>
>> J'avais ecrit ca pour passer le temps, lors d'une réunion ou il y avait 
>> bcp de monde et lors de laquelle je m'ennuyais....
>> Ca marchait tres bien tant qu'on le lancait en etant dans gdcmData.
>
> c'est que je me disais, ou bien tu peux parfaitement copier l'image dans 
> gdcm-bin...
>
>> Je ne sais plus trop pourquoi il s'est retrouve dans 'Testing', alors 
>> qu'il n'a rien a y faire (pas plus que ReadPapyrus or 
>> ReadOverlays).C'etait juste un bout de code, s'appuyant sur des 
>> primitives de bas niveau, qui va recuperer/positionner des info un peu 
>> exotiques.
>> Il suffisait d'ajouter GDCM_DATA_ROOT dans le nom du fichier pour que ca 
>> passe.
>
> ja sais mais mon point c'etait de montrer que meme avec un dashboard gdcm 
> reponds oui tout ce passe bien ... alors que c'est archi faux !
>
>> Personne, en effet.
>> Pas plus toi que les autres.
>> Je prend une heure demain matin, j'ajoute des try-catch dans tous les 
>> tests.
>> Est-ce que cela changera le problème?
>
> C'est tres gentil, mais non je ne pense pas que ca reglera le probleme. Un 
> utilisateur va se lancer dans l'utilisation de gdcm. Il va faire une mini 
> demo (new gdcm::File) avec une typo dans le nom de fichier... et gdcm va 
> lui dire ben oui ta va bien j'ai bien lu le fichier inexistant.
>
> Donc non: on ne fais pas de try catch. Le seul try catch en c++ qui est 
> possible c'est celui du 'new'. Genre on atteint les limites physique de la 
> machine et la ben oui faut bien faire un traitement de derniere chance. 
> Mais entre nous tu ne peux pas demander a un util de faire des try catch 
> de partout dans son code.
>
> En revanche tu peux parfaitement faire:
>
> gdcm::Serie s =
> s.SetDirectory( "bla" );
>
> try
>   {
>   s.GetFirstSerie()
>   }
> catch
>   {
>    cerr << "Echec parce que:" << error.Print() ...
>   }
>
> dans la meme genre l'utilisateur devrait mettre un try/catch au moment de 
> l'ecriture:
>
> gdcm::FileHelper f
>
> try
>   f.Write()
> catch
>   cerr << "Echec"
>
>
> Entre parenthese je sais meme pas si c'est possible de mettre un try catch 
> sur la construction d'un objet: comment tu fais pour le declarer:
>
> try
> {
>    gdcm::File f("");
> }
> catch
> {
> }
>
> f.GetImageData() -> echec du compilo
>
> -> on est sortie du scope , on n'a plus access a f. Ca veut dire que ne 
> peut plus faire d'objet sur la pile, a chq fois il faudrait faire un 
> pointeur puis affectation:
>
> gdcm::File *f;
>
> try
> {
>    f = new gdcm::File("");
> }
> catch
> {
> }
>
>
> DU DELIRE !
>
>> La derniere version du diagramme de classes pour décrire l'entete ne me 
>> choque plus.
>> En revanche, la partie 'lecture/decompression' devra probablement etre 
>> entierement réécrite.
>> Vouloir lire *tout* le fichier d'un seul coup, c'est du pur délire !
>> Lorsqu'on aura des multiframes de 2 Giga Octets, comme ceux de 
>> Jean-Michel Rouet
>> (on en a deja, de plus petits, de 200 MegaOctets), il faudra bien qu'on 
>> fasse du frame by frame reading, pour permetre a l'utilisateur de de 
>> garder *lors de la lecture* que les frames dont il a besoin (et pas une 
>> fois que tout est lu ...).
>> Et la, ca va secouer ...
>
>
> Exact je n'y avais pas penser mais tu as parfaitement raison. Dans le cas 
> d'image de ce type il faut pouvoir faire qlq chose du genre:
>
>
> gdcm::File f(); //vide
> s.SetVolumeOfInterest(0,512,0,512,0,10);
>
> try
>    f.Read()
> catch
>    cerr << "Echec lors de la lecture"
>
> C'est vraiment important de faire le VRAI traitement en dehors de la 
> construction de l'image IMHO.
>
>
>> Pourrais-tu nous les communiquer.
>
> C'est sur papier, je recopie, et je fais un mail. J'espere que mes notes 
> seront relisible. En gros j'applique la methode XP: j'ecris d'abords les 
> tests et ensuite j'ecris la lib.
>
> Mathieu
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib