[Dcmlib] [ITK-gdcm] update: plus constructif

[Mathieu Malaterre]

Ok maintenant que j'ai crie' je vais mieux.

Donc les points pour moi qui sont essentiels:

- Avoir 100% des tests sur toutes les machines, j'ai encore des trucs 
bizarre sur Win32 (borland/VC6).

- Reduire drastiquement la consommation memoire. DASH4 une machine qui 
fais les ~800 tests VTK sans *aucun* problemes, se mets a genoux sur 
TestAllReadImageWrite. La consommation memoire monte a 220Mo alors que 
la machine n'a /que/ 256Mo

- Ca doit etre lie au point precedent, mais il faut *enlever* les memory 
leaks. Sur Win je suis meme pas sur que le system est capable de 
retrouver ces petits meme apres la fin de l'execution d'un programme gdcm.

- Revoir l'API actuelle serieusement. Je vais essayer de reprendre les 
points que j'ai trouver en creusant dans gdcm.

	1. Je continu a ne pas aimer les passages pas pointeurs, je prefererais 
les passages pas reference. L'avantage c'est que ca anihilerait le 
probleme de leaks si l'ont reduit l'usage de raw pointer. *Ou* alors on 
utilise les auto_ptr de la stl

	2. Des methodes longues de 20 caracteres. Des commentaires gigantesque 
(en XP le code ne devrait pas avoir a etre commenter vu qu'un test en 
demontrerait le comportement). Donc beaucoup plus de tests. A peine 70% 
du code est teste' (sans compter la lib jpeg)

	3. Plein d'inconsistences. Usage indifferent de "unkn", "??", 
"Unknown", GDCM_UNFOUND. Des methodes utilises TagKey/TagName dans le 
fichier .h et dans le fichier .cxx on passse a std::string

	4. Enormement de variable globales:

const std::string GDCM_UNFOUND   = "gdcm::Unfound";
const std::string GDCM_BINLOADED = "gdcm::Binary data loaded";
const std::string GDCM_NOTLOADED = "gdcm::NotLoaded";
const std::string GDCM_UNREAD    = "gdcm::UnRead";

	qui pollue le namespace. Meme si gdcm resoud ce probleme, je ne pense 
pas que se soit une bonne pratique de programmation.

	5. Du code dupliquer de partout.

Je suis sur que j'en oublie. Mais voila pour moi les points essentiels a 
traiter avant d'ajouter des nouvelles features a gdcm.

Mathieu
Ps: sinon pour l'ecriture des fichiers dicom, j'aurais aimer une 
distinction entre un reader et un writer. Ou en stl : un ifstream/ofstream