[Dcmlib] TestMakeIcon : exit dans gdcmDocument]

[Jean-Pierre ROUX]

At 11:24 -0400 25/04/05, Mathieu Malaterre wrote:
>Jean-Pierre Roux wrote:
>>
>>Mathieu Malaterre wrote:
>>
>>>
>>>J'ai rajouter une ligne: gdcmDocument fais un exit si tu lui 
>>>passes un nom de fichier qui n'existe pas... le test TestMakeIcon 
>>>passe une image sans full path...
>>>
>>
>>Ce qui existait n'etait pas tres satisfaisant (on ne prevenait pas 
>>l'appelant si on n'arrivait pas a ouvrir un fichier ...)
>>Je ne savais pas comment faire, alors je l'avais laissé comme ca, 
>>me disant qu'une methode finirait bien par renoyer un copde 
>>d'erreur, un peu plus loin.
>>L'exemple de TestMakeIcon a montre qu'il n'en n'etait rien, puisque 
>>le test s'effectuait 'successfull', alors que le full path name de 
>>l'image etait faux.
>>
>>La solution actuelle, qui consiste a faire un 'exit' au plus 
>>profond des entrailles de gdcm me choque.
>>Ce n'est pas a une fonction de tres bas niveau de dire si le 
>>programme de l'utilisateur s'arrete ou non!
>>Il faut pouvoir informer l'utilisateur que qq chose a foiré dans le 
>>constructeur.
>>
>>Je ne maitrise pas assez les subtilites du C++, mais ne serait-il 
>>pas possible de transposer l'equivalent du 'errno' du C (une 
>>variable globale -en C- qui indique le code d'erreur dans le cas ou 
>>la valeur retournée par la fonction n'indique pas -ou indique de 
>>maniere insuffisante- que ca a casse, ou *ce qui* a casse)?
>>
>>Dans la version actuelle (avec exit), la seule maniere pour 
>>l'utilisateur d'etre sur que son programme ne lui pete pas dans les 
>>doigts serait de verifier (par fopen puis fclose) que son fichier 
>>est bien ouvrable.
>>Ce qui va encore ralentir le bazar ...
>
>C'est encore un des gros problemes de gdcm, je ne suis vraiment pas 
>satisfait de l'archi. Deja le premiere des choses qui me rend dingue 
>c'est qu'un test qui ne marche pas depuis bientot 2 mois a toujours 
>ete vert (jusque qu'e ce que j'utilise .Net FreeC++ + nmake).
>

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.
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.

>Mais effectivement pour effleurer le probleme de la propagation 
>d'erreur beaucoup de chose sont faites a 'creation time'. On creer 
>un objet gdcm::File a partir d'un file name, un constructeur c++ ne 
>retourne rien sur la pile. Donc la seule solution c'est de lancer 
>une exception. Jusqu'a le rien de bien choquant. Mais mon gros 
>probleme c'est que PERSONNE, je dis bien PERSONNE ne fais de 
>try/catch sur une construction d'objet c++. C'est du pur delire.
>

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?

>Il y a un profond probleme du au system d'heritage de gdcm qui me 
>deplait de plus en plus. Et je suis de tente de demarrer un projet 
>from scratch pour me debarrasser definitivement de ca.

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 ...


> Au passage est-ce que d'autre personne partage mon opinion: cad 
>qu'il y a aeu des choix fais a la base de gdcm qui sont faux et qui 
>font que meme un couche de refactoring(*) ne suffirait pas regler ?
>
>J'ai commencer a dresser la liste des attentes d'une lib IO pour le 
>cas des images DICOM et je crois avoir fais le tour.

Pourrais-tu nous les communiquer.
En ce qui me concerne, j'ai mis sur le serveur, dans la partie 
'News', sous le titre 'Missing features', les choses qui manquent.

JPRx

>
>Mathieu
>(*) Refactoring: Improving the Design of Existing Code
>by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

  Jean-Pierre ROUX
  UMR CNRS 5515-CREATIS
  Laboratoire de Radiologie Experimentale
  Hopital Cardiologique
  28 Avenue du Doyen LEPINE
  B.P. Lyon-Montchat
  69394 Lyon Cedex 03

  Tel      : (+33) 04 72 35 74 12
  Fax      : (+33) 04 72 68 49 16
  URL      : http://www.creatis.univ-lyon1.fr
  e-mail   : jpr at creatis.univ-lyon1.fr