[Dcmlib] GDCM commit

[Mathieu Malaterre]

Salut,

   J'ai fais des commit, rien de tres spectaculaire, juste j'ai beaucoup de mal a lire les sources de gdcm. Est-ce qu'on peut se mettre d'accord sur certaines convention d'ecriture:

- pas de printf

- pas de parentheses aux return:

return true;

au lieu de

return(true);

- pas besoin de void quand la fonction ne prend pas de parametre:

foo()

au lieu de

foo(void)

- le parenthesage:

void foo() {
...
}

au lieu

void foo()
{
...
}

- Est-ce que "virtual" est repete meme dans les classes heritees (convention d'ecriture car non necessaire).

- Il n'y a besoin de specifier explicitement 'inline' lorsqu'une methode est implementee dans la classe (fichier header).
http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.8

- Tolere pour l'instant: sprintf, FILE*
Mais j'aimerais passer a une approche plus C++ avec les iostream dans l'avenir

Je ne reproche rien a personne, je me porte meme volontaire pour les faire. Donc est-ce que ca vous va ou vous voulez des choses differentes?


---

Sinon plus grave je suis tombe sur ca dans gdcmFile:

1.

void * gdcmFile::GetImageDataRaw () {
  if (Header->HasLUT())
     /// \todo Let gdcmHeadar user a chance to get the right value
       /// Create a member lgrTotaleRaw ???
     lgrTotale /= 3;
  PixelData = new unsigned char[lgrTotale];
...

Ca veut dire que plus j'appelle cette methode plus la taille de l'image est petite.
Plus serieusement, on peut pas simplifier les var membres de gdcmFile.
Ex1:
  gdcmHeader *Header;
  bool SelfHeader;

Y'a t'il vraiment besoin du booleen, est-ce qu'on ne peut pas directement regarder si Header est different de NULL ?

Ex2:
void* PixelData;
Est-ce que ce membre va disparaitre vu que l'image est dans le Header (cf dernier mail de JP).

Ex3:
  size_t lgrTotaleRaw;
  size_t lgrTotale;
  int PixelRead;
  int Parsed;

Je suppose que c'est liee a la question 2, mais qd meme on ne peut pas avoir une seule lgtTotale. Pour moi l'operation de tranformation via lookup table est commande par l'utilisateur. Ca veut dire qu'un volume va etre cree a la demande de l'utilisateur qd l'image a une lookup table
et qu'il veut appliquee celle la.
Autre ex, si on lit + ecrit l'image est-ce que l'on veut vraiment appliquee la lookup table a l'image ? En plus vu qu'il n'y a qu'un seul void* PixelData si l'utilisateur demande d'abord le volume raw puis le volume filtree puis encore le volume raw on ne peut pas mettre en cache les volumes precalcules.

2.

Le choix unsigned char vs char semble complement arbitraire. Par defaut sur toutes les plateformes (sauf SUN), char est signed donc il y a bien une difference. Est-ce qu'on peut donc tout passer en unsigned char ?

3.
C'est quoi: bool ParsePixelData(); Normalement VC++ ne sait pas gerer les fonctions non implementees...


----

De maniere plus general, j'aurais aime un retour d'experience de cmake.
J'ai compris que pour l'installation python ce n'etait pas au point.
Mais en ce qui concerne :
- la compilation
- interface pour regler les options de compil
- les tests
- l'install des lib c++

Meme si ce n'est que des questions merci de me les envoyer

Voila voila merci d'avoir lu jusque la,
Mathieu

Au fait j'ai envoyer sur fr.comp.lang.c++ le probleme des const char* + string ... j'espere que j'aurais une reponse.