<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
Mathieu Malaterre wrote:<br>
<blockquote type="cite"
cite="mid20040623035829.TPQG24254.fep01.biz.rr.com@%5B127.0.0.1%5D">
<pre wrap="">Salut,<br><br> 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:</pre>
</blockquote>
<br>
Pas d'objection à tes suggestions, SAUF pour les inline.<br>
<br>
Le code complet de la fonction doit effectivement être dand le .h (on est
bien d'accord : le compilo ne pourrait pas intégrer le code directement dans
l'application appelante s'il ne le connait pas --> unresolved external
lors du link)<br>
<br>
Mais si elle n'est pas déclarée inline, elle sera traitée comme une fonction
normale (pas inline)<br>
<br>
le lien <br>
<a class="moz-txt-link-freetext" href="http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.8">http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.8</a><br>
donne une description parfaitement confusionniste à ce sujet.<br>
<br>
--------------------------------------------------------------------------------------------------<br>
<div class="FaqTitle">
<h3>[9.6] How do you tell the compiler to make a non-member function <tt>
inline</tt>?</h3>
</div>
<p>When you declare an <tt>inline</tt> function, it looks just like a normal
function:<br>
</p>
<div class="CodeBlock"> <tt> void f(int i, char c);<br>
<br>
===> Puisque la définition se fait en même temps que la déclaration, à
quoi ça sert de présenter les deux, de manière contradictoire ?!?<br>
</tt> </div>
<p>But when you define an <tt>inline</tt> function, you prepend the function's
definition with the keyword <tt>inline</tt>, and you put the definition into
a header file: </p>
<div class="CodeBlock"> <tt> inline<br>
void f(int i, char c)<br>
{<br>
</tt><em><small>...</small></em><tt><br>
} </tt> </div>
<p>Note: It's imperative that the function's definition (the part between
the <nobr><tt>{</tt>...<tt>}</tt></nobr>) be placed in a header file, unless
the function is used only in a single .cpp file. In particular, if you put
the <tt>inline</tt> function's definition into a <tt>.cpp</tt> file and you
call it from some other <tt>.cpp</tt> file, you'll get an "unresolved external"
error from the linker. </p>
--------------------------------------------------------------------------------------------<br>
<blockquote type="cite"
cite="mid20040623035829.TPQG24254.fep01.biz.rr.com@%5B127.0.0.1%5D">
<pre wrap=""><br><br>- pas de printf<br>- pas de parentheses aux return:<br>return true;<br>au lieu de<br>return(true);<br><br>- pas besoin de void quand la fonction ne prend pas de parametre:<br><br>foo()<br>au lieu de<br>foo(void)<br></pre>
</blockquote>
<br>
<blockquote type="cite"
cite="mid20040623035829.TPQG24254.fep01.biz.rr.com@%5B127.0.0.1%5D">
<pre wrap=""><br>- le parenthesage:</pre>
</blockquote>
Ca a l'air d'être un problème religieux !<br>
Il faut qu'on réunisse un web-concile à ce sujet, car il est clair que s'il
y a deux chapelles dans le Labo, dont les affidés font des modifs en sens
inverse chaque fois qu'ils ouvrent un .cxx, on n'est pas prêt de s'en sortir
!<br>
<blockquote type="cite"
cite="mid20040623035829.TPQG24254.fep01.biz.rr.com@%5B127.0.0.1%5D">
<pre wrap=""><br><br>void foo() {<br>...<br>}<br><br>au lieu<br><br>void foo()<br>{<br>...<br>}<br><br>- Est-ce que "virtual" est repete meme dans les classes heritees (convention d'ecriture car non necessaire).<br><br>- Il n'y a besoin de specifier explicitement 'inline' lorsqu'une methode est implementee dans la classe (fichier header).<br><a class="moz-txt-link-freetext" href="http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.8">http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.8</a></pre>
</blockquote>
Voir ma remarque + haut.<br>
<blockquote type="cite"
cite="mid20040623035829.TPQG24254.fep01.biz.rr.com@%5B127.0.0.1%5D">
<pre wrap=""><br><br>- Tolere pour l'instant: sprintf, FILE*<br>Mais j'aimerais passer a une approche plus C++ avec les iostream dans l'avenir</pre>
</blockquote>
<br>
A part le fait de compliquer l'écriture, ça a un réel intérêt les iostream
?<br>
<blockquote type="cite"
cite="mid20040623035829.TPQG24254.fep01.biz.rr.com@%5B127.0.0.1%5D">
<pre wrap=""><br><br>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?<br><br><br>---<br><br>Sinon plus grave je suis tombe sur ca dans gdcmFile:<br><br>1.</pre>
</blockquote>
Bien d'accord.<br>
Il y a des modifs 'profondes' à faire la-dedans (qui ne changeront pas l'API)<br>
<blockquote type="cite"
cite="mid20040623035829.TPQG24254.fep01.biz.rr.com@%5B127.0.0.1%5D">
<pre wrap=""><br><br>void * gdcmFile::GetImageDataRaw () {<br> if (Header->HasLUT())<br> /// \todo Let gdcmHeadar user a chance to get the right value<br> /// Create a member lgrTotaleRaw ???<br> lgrTotale /= 3;<br> PixelData = new unsigned char[lgrTotale];<br>...<br><br>Ca veut dire que plus j'appelle cette methode plus la taille de l'image est petite.<br>Plus serieusement, on peut pas simplifier les var membres de gdcmFile.<br>Ex1:<br> gdcmHeader *Header;<br> bool SelfHeader;<br><br>Y'a t'il vraiment besoin du booleen, est-ce qu'on ne peut pas directement regarder si Header est different de NULL ?<br><br>Ex2:<br>void* PixelData;<br>Est-ce que ce membre va disparaitre vu que l'image est dans le Header (cf dernier mail de JP).<br><br>Ex3:<br> size_t lgrTotaleRaw;<br> size_t lgrTotale;<br> int PixelRead;<br> int Parsed;<br><br>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 tra
nformation 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<br>et qu'il veut appliquee celle la.</pre>
</blockquote>
En fait, c'est lorsqu'on a une image gray level + LUT qu'on 'fabrique' une
zone mémoire contenant une image RGB, par GetPixelData, ou une image Gray
Level, par GetPixelDataRaw.<br>
<blockquote type="cite"
cite="mid20040623035829.TPQG24254.fep01.biz.rr.com@%5B127.0.0.1%5D">
<pre wrap=""><br>Autre ex, si on lit + ecrit l'image est-ce que l'on veut vraiment appliquee la lookup table a l'image ? </pre>
</blockquote>
Lorsqu'on réécrit l'image, c'est forcement l'image avec des pixels RGB :<br>
- si elle était stockée sous forme Plan R+ Plan G + Plan B, ou sous forme
de pixels YBR, ce qui n'est pas génant dans ce cas là, <br>
- si elle était stockée sous forme de GrayLevel + LUT, et là, ça se discute
<br>
<blockquote type="cite"
cite="mid20040623035829.TPQG24254.fep01.biz.rr.com@%5B127.0.0.1%5D">
<pre wrap="">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.<br><br>2.<br><br>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 ?<br><br>3.</pre>
</blockquote>
<blockquote type="cite"
cite="mid20040623035829.TPQG24254.fep01.biz.rr.com@%5B127.0.0.1%5D">
<pre wrap=""><br>C'est quoi: bool ParsePixelData(); Normalement VC++ ne sait pas gerer les fonctions non implementees...</pre>
</blockquote>
C'est une fonction qui inspecte l'organisation du Dicom Element des Pixels
<br>
En cas d'embedded JPEG, ou embedded RLE, ca peut relever d'un foutoir sans
nom - soit des trucs qui ressemblent à des SQItems dans etre dans un SeqEntry
et qui contiennent les 'JPEG fragments', soit une table de longueur variable
contennant l'offset du début de chaque fragment, etc.<br>
Elle n'est pas appellée dans la dcmLib elle même, seulement dans un exécutable.
Elle est précieuse pour savoir si une image Jpeg qui pête a une description
kasher pour son Pixel Element.<br>
La méthode se trouve dans :<br>
gdcmParsePixels.cxx<br>
comme methode de la classe gdcmFile: <br>
bool gdcmFile::ParsePixelData(void) {<br>
...<br>
}<br>
Je ne l'ai pas mise dans gdcmParsePixels.cxx pour ne pas allonger le temps
de compile.<br>
<br>
C'est sa présence dans un autre .cxx qui pose un pb ?<br>
<blockquote type="cite"
cite="mid20040623035829.TPQG24254.fep01.biz.rr.com@%5B127.0.0.1%5D">
<pre wrap=""><br><br><br>----<br><br>De maniere plus general, j'aurais aime un retour d'experience de cmake.<br>J'ai compris que pour l'installation python ce n'etait pas au point.<br>Mais en ce qui concerne :<br>- la compilation<br>- interface pour regler les options de compil<br>- les tests<br>- l'install des lib c++<br><br>Meme si ce n'est que des questions merci de me les envoyer<br><br>Voila voila merci d'avoir lu jusque la,<br>Mathieu<br><br>Au fait j'ai envoyer sur fr.comp.lang.c++ le probleme des const char* + string ... j'espere que j'aurais une reponse.<br><br><br></pre>
</blockquote>
<br>
</body>
</html>