[Dcmlib] GDCM commit

Wed Jun 23 15:46:51 CEST 2004

----- Original Message ----- 
From: "Eric Boix" <Eric.Boix at creatis.insa-lyon.fr>
To: "Mathieu Malaterre" <mathieu.malaterre at kitware.com>
Cc: <dcmlib at tux.creatis.insa-lyon.fr>
Sent: Wednesday, June 23, 2004 12:20 PM
Subject: Re: [Dcmlib] GDCM commit

> Quoting Mathieu Malaterre <mathieu.malaterre at kitware.com>:
> >    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:
> J'en reve depuis longtemps. Un coding style NOW ! On met tout cela
> par ecrit dans gdcm/DEVELOPPER, et on l'adopte en commun ?
>
> > - pas de printf
ok pour moi aussi

> > - pas de parentheses aux return:
> > return true;
> D'ac.
Soit...

> > - pas besoin de void quand la fonction ne prend pas de parametre:
> D'ac.
Par définition dans les dfd, une méthode n'ayant pas de paramètres explicite
peut prendre tous les paramètres (c'etait pour le C, pour le C++ je sais
pas).
void signifie ainsi clairement qu'il n'y a pas de paramètres.
Je suis donc personnelement pour être propre et metre le void (et ca ne
coute pas
grand chose à faire je pense).

> > void foo() {
> > ...
> > }
> Pas d'objection. On peut garder le mode VTK en interne au fonctions
> i.e. conserver des choses du genre
>    if (bozo)
>    {
>    ...
>    }
>    else if ( )
>    {
>    ...
>    }
> versus
>    if (bozo) {
>    ...
>    } else if ( ) {
>    ...
>    }
> ?????
> C'est juste une question d'habitude, mais dans certaines fonctions
> spagheti, cela me simplifie la lecture. Ceci dit, c'est juste une
> question de gout et je me plie facilement a la majorite'. L'homogeneite'
> du code me semble plus importante que mes preferences ;-)
Je suis d'accord avec Eric, la 2eme version (alignant les acolades) permet
un code plus clair et lisible, surtout pour les fonctions complexes en terme
de if et while. Je propose d'aligner les acolades sur le if (ou while) et
non
pas comme dans vtk sur la ligne suivant... donc avoir le code juste au
dessus
Perso, je propose d'etre cohérent sur toute la ligne, donc toujours aligner
les
acolades... pour les fonction ou en interne du code...

> > - Est-ce que "virtual" est repete meme dans les classes heritees
> >  (convention d'ecriture car non necessaire).
> Ben a vrai dire, je vois pas l'interet de le repeter, mais je peux
> faire l'effort.
Par définition (je crois que c'est dit aussi dans le stroustrup (dsl si ca
s'ecrit pas comme
ca)), ne pas remettre le virtual sur une méthode dans une classe dérivée
désigne le fait
que cette méthode ne doit pas être surchargée dans les futures classes
dérivantes.
Ce qui se passe après dans le compilo... j'en sais rien, mais ce n'est pas
une référence
à mon gout.

> > - Il n'y a besoin de specifier explicitement 'inline' lorsqu'une methode
> > est implementee dans la classe (fichier header).
> D'ac.
Même si c'est pas obligatoire, ca rend le code plus clair, donc oki pour moi
Mais pour ces méthodes, où met-on les commentaires doxygen ?

> > - Tolere pour l'instant: sprintf, FILE*
> > Mais j'aimerais passer a une approche plus C++ avec les iostream dans
l'avenir
> Entierement d'accord. Ceci dit, il y a un certain nombre de choses
> que je ne sais pas faire a coup de << ou >>, et donc que je n'ai pas su
> proposer a JPR. En particulier je ne sais pas lire/ecrire un paquet de
bytes
> en gerant la conversion des endianries.
> Il faudrait que JPR nous dise quelles sont ces operations atomiques
> en matiere de fread et fwrite, pour proposer une fac,on C++ et portable
> de faire.
> En attendant j'avais essaye' de factoriser les choses (en particulier les
fread)
> dans des fonctions genre ReadInt16, mais cela a un peu derape'...
vi... ce serait à faire. Personnelement, je ne sais pas utiliser les << et
>> lorsqu'on
a à faire à un fichier binaire... mais je suis avide d'apprendre.

Je rajouterai dans le coding style :
 - avoir des espace (au lieu de tab) avec un padding de 3... même si on le
fait déjà,
je pense qu'il faut le mentionner pour les générations futures.
 - le placement des espaces autour des ( , = et autre symble.
 - lors de la définition ou l'utilisation de pointeur... coller le * à la
variable concernée,
et non pas au type. Donc avoir le code suivant :
   void *foo;
et non pas
   void* foo;

J'ai joint un fichier reprenant les coding style accepté et ceux encore à
discution...
il est en francais... a qui veut bien le passer en anglais s'il veut. Je
pense qu'on peut
partir de cette base pour le document final. Les points sont mis en vrac...

> FINALEMENT:
>  * Je propose que l'on ECRIVE un coding style leger mais OBLIGATOIRE.
>  * On passe immediatement en feature freeze.
>  * On ecrit une test suite decente en C++.
>  * On nettoie intensivement le code en se tenant au coding style.
>  * On utilise vraiment gdcm/TODO pour noter ce qui doit-etre fait.
>    Quand quelqu'un traite une entre'e, il le signale dans le TODO
>    pour eviter de ce marcher sur les pieds avec une gueguerre des commits.
>
> Quand je dis ON, c'est NOUS avec JE !
oki, et avec joie. Il est tent de pouvoir obtenir une version stable
win32/linux et
c++/python

> > 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++
> Bien que mon experience avec cmake soit encore embryonnaire, voila ce
> que je peux en dire:
>  * cela nous evite de gerer les .dsw a la main: rien que pour cela
>    je suis preneur.
>  * je n'ai jamais eu a editer un makefile generes sous un*x, ce qui
>    prouve que les choses sont propres (alors que sous les autotools,
>    il m'a parfois fallu fouiller pour comprendre mon erreur dans un
>    Makefile.am). Mais peut-etre que sans Mathieu, j'aurais du le faire...
>  * l'interface manuelle me semble moins sympa que des flags en ligne
>    de commande passe's a autogen.sh. A chaque fois que je checkout
>    gdcm, je suis force' de modifier les memes choses a la main.
>    J'ai cru comprendre qu'en copiant le bon fichier on pouvait eviter
>    cela mais je ne sais pas faire...
>  * ctest me semble une tres bonne chose. Je n'ai pas encore regarde'
>    le lien avec Dart. Je devrais. Je ne sais pas encore comment on
>    fait des assert pour une test suite. Il faut que je regarde
>    Test/ShowDicom pour apprendre.
>  * La gestion de SWIG sera sans doute meilleure dans CMAKE 2.0.
>    Ceci dit, python/distutils est aussi tres le'ge' pour le support
>    de swig, alors que c'est droit devant avec les autotools.
>    Remarque: le fichier gdcmbin/gdcmPython/gdcm_wrap.cxx n'est pas
>              nettoye' par un make clean. C'est regretable, mais
>              ce n'est sans doute pas une limitation de cmake.
>    Je pense que la passage a swig (patche' certes) dans cable, forcera
>    KitWare a un meilleur support de Swig. Wait and see.
>  * Pour l'instal des libs, cela pose un ch'ti pb avec les pythoneries.
>    En particulier il faut adapater les import pour decliner le nom
>    de la .so ou de la .dll a charger (sous Un*x il y a un prefix de lib
>    et pas sous WIn32). Ceci dit, je pense que cela respecte plus la facon
>    unix de faire, et c'est a nous de nous adapter.
>  * La partie python est encore tes largement pe'te'e et difficilement
>    exploitable. Il faut qu'on y travaille, mais Benoit et moi avons
souffert
>    sous Win32 en particulier, a cause de collisions de nom entre les dll
et
>    les .py (que veut dire import gdcm quand gdcm.dll et gdcm.py existent
>    alors que sous Un*x cette collisision est evite'e avec libgdcm.so et
>    gdcm.py). Plus la dessus plus tard...
>
> Un bemol tout de meme: c'est Mathieu qui a ecrit tout les CMakefile
> et je ne suis pas certain que tout seuls les choses aient ete aussi
> simple... (en particulier je n'ai jamais ouvert la doc de CMAKE pour
> essayer de rajouter une fonctionalite': une chose est sure, la doc
> des autotools n'est pas triviale...).
CMake facilite les changements de nom de fichier ou l'ajout de fichiers pour
windows.
Et c'est droit devant pour compiler. Donc j'ai contre l'utiliser.
Pour les flags, y en a plein d'incompréhensible, mais tant qu'il y a pas
besoin d'y toucher,
ca me convient pour l'instant.
Perso, j'en ai besoin qu'en python... même si je fais la recompilation de
tout sous msvc,
et pour python... ben c'est encore bien la merde... mais ca s'arrange tout
doucement.
Je pense qu'on pourra s'occuper de Python lorsque déjà la partie C++ sera
posée et en
phase finale de stabilité. Et il faudrait déjà qu'en interne, on fasse des
choix propre sur
comment utiliser gdcm avec python (je parle pas de l'interface accessible en
python,
mais sur le résultat obtenu par un import... mais il faudra aussi parle un
jour de l'interface...).

Benoit
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: coding.txt
URL: <http://www.creatis.insa-lyon.fr/pipermail/dcmlib/attachments/20040623/cbd579a1/attachment.txt>