Tu es sur de ne pas te tromper ?
http://c.developpez.com/faq/cpp/?pag..._list_list_fct
Version imprimable
Tu es sur de ne pas te tromper ?
http://c.developpez.com/faq/cpp/?pag..._list_list_fct
Ah oui en effet, d'où le warning qui s'affichait qui disait que ça renvoyait toujours true :p.
Par contre si j'ai une fonction template avec un type T, si c'est entier, un entier flottant... Je peux faire x = T(); et x vaut 0. Donc logiquement je peux faire int x = int() ?
Si ça marchait comme ça, ça se saurait. Tu ne peux pas assurer que la variable sera initialisée à 0.
Ah bon ? Pourtant ça a toujours bien marché dans mes fonctions templates quand je faisais ça avec des types primitifs, sur mes deux compilos.
Personnellement, sachant que dans certains cas, ça ne donne pas la bonne réponse - mode debug ou autres -, et prévoir ce genre de chose dans sa bibliothèque est indispensable, donc traits et quoiqu'il arrive le problème est réglé car résolu explicitement.
Oui. C'est une 0-initialisation (j'ai oublié le terme exact) connue et abondament utilisée dans le mode merveilleux des templates.Citation:
Envoyé par Bakura
(compilé avec GCC-cygwin (make en fait) sans option particulière (ni -g, ni -O; qui au demeurant ne changent pas grand chose))Code:
1
2
3
4
5
6
7
8
9
10
11 #include <iostream> int main (int argc, char **argv) { int i = int(); // inverser ne change rien int j; std::cout << "i:" << i << std::endl;; std::cout << "j:" << j << std::endl;; return 0; }
Code:
1
2
3
4 F:/cygwin/bin/bash.exe -c "./0-init.exe " i:0 j:1628821313 Hit any key to close this window...
Ok donc c'est bien ça. Je me disais bien que je l'avais déjà vu plusieurs fois le coup du T() dans du code template :).
Waouuaaaa Quels posts ... :D
Alors les gourous, comment mieux optimiser cela :yaisse2:
Ici, les millisecondes prennent beaucoup d'importance.
http://www.developpez.net/forums/sho...d.php?t=366832
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42 // #include <cv.h> #include <highgui.h> #include <stdio.h> #include <cvcam.h> // int frame=0; // void callback(IplImage* img) { int i,j,k,x,y; int iwd=img->widthStep; char *idt=img->imageData; int channels = img->nChannels; double t1=cvGetTickCount( ); frame++; for (x=0;x<320;x++) { for (y=0;y<240;y++) { idt[y*iwd+x*channels]=0; // Pixel Bleu //idt[y*iwd+x*channels+1]=0; // Pixel Vert //idt[y*iwd+x*channels+2]=0; // Pixel Rouge } } printf("Temps 1 %d %f \n",frame,cvGetTickCount( )-t1); } int main( int argc, char** argv ) { int ncams = cvcamGetCamerasCount( ); cvcamSetProperty(0, CVCAM_PROP_ENABLE , CVCAMTRUE); cvcamSetProperty(0, CVCAM_PROP_CALLBACK ,(void *)callback); if( !cvcamInit() ) return 0; cvcamStart(); cvWaitKey(0); cvcamStop(); cvcamExit(); }
A part remplacer les x++ et y++ par ++x et ++y et remplacer :
parCode:
1
2
3
4
5
6
7
8
9
10 for (x=0;x<320;x++) { for (y=0;y<240;y++) { idt[y*iwd+x*channels]=0; // Pixel Bleu //idt[y*iwd+x*channels+1]=0; // Pixel Vert //idt[y*iwd+x*channels+2]=0; // Pixel Rouge } }
Je ne vois pas, et puis le coup du ++x et x++ je ne pense pas que tu gagnes beaucoup, et le coup de calculer l'expression à l'extérieur de la boucle plutôt qu'à l'intérieur (parceque dans ton second for, le x*channels restera le même durant les 240 itérations), mais je pense que le compilo est assez intelligent pour faire cette optimisation lui même. Sinon, si tu ne modifies pas ton objet img, tu pourrais déclarer comme un pointeur constant (const IplImage * img).Code:
1
2
3
4
5
6
7
8
9
10 for (x=0;x<320;++x) { int xMult = x * channels; for (y=0;y<240;++y) { idt[y*iwd+xMult]=0; // Pixel Bleu //idt[y*iwd+x*channels+1]=0; // Pixel Vert //idt[y*iwd+x*channels+2]=0; // Pixel Rouge } }
Sinon, si tu fais du C++, remplace printf par cout. Ca va rien améliorer mais c'est tout de suite plus beau :aie:
Et peut-être permuter les deux boucles pour éviter les cache miss.
Le tutorial de GIL explique bien comment optimiser ce genre de choses.
@Bakura.
Mince, j'ai loupé le coup du calcul a l'extérieur de la boucle Y. Merci. :D
Le "printf n'est pas définitif mais c'est en effet une idée.
Le compilateur ou plutot l'IDE c'est DEV C++ ou Code::Block. Le compilateur : MingW ou Gcc.
Cela dit, comme tu le sais sans doute, Code::Block peut s'interfacer de plus avec OpenWatcom, Borland C++ 5.5, Visual C++ Toolkit 2003. Un de ces compilos est sans doute le meilleur?. Lequel?
"Sinon, si tu ne modifies pas ton objet img, tu pourrais déclarer comme un pointeur constant (const IplImage * img)."
Dans ce traitement l'image est modifiée mais l'idée est "mémorisée" pour les autres cas. :P
@HanLee
"Et peut-être permuter les deux boucles pour éviter les cache miss."
Je suis largué. C'est presque du Chinois pour moi :D :D :D
@loufoque
Merci. Super lien :P
Jean-Pierre.
Il faut faire attention avec les i++ et les ++i dans un for il n'y a pas de problème mais dans un while c'est autre chose :
Code:
1
2
3
4
5
6
7
8 int i = 10; while(i--) cout << i << endl; i = 10; cout << endl; while(--i) cout << i << endl;
Normal mais il faut juste ne pas l'oublier parce qu'en lisant le post j'ai entendu partout remplacer ça par ça truc par truc mais il faut toujours considérer le context... VoilàCitation:
Envoyé par console
Un truc non abordé...
On peut écrire cela :
Mais est-ce mal :mrgreen: ?Code:
1
2
3
4 for (i=0, j=0 ; i<MAX ; i++, k+=4) { //du code }
J'avoue ne pas trouver grand chose à ce sujet...
Il faut juste que i et k soient du même type.
Ah, mais alors, pourquoi ?
J'aimerais bien avoir des détails à ce sujet...
C'est comme ça, il faut que le retour de chaque instruction dans une instruction avec des ',' soit du même type.
C'est valable uniquement pour les boucles ou pour tout le reste ?
Si c'était valable pour le reste, une instructionfree(ptr), ptr=NULL; ne compilerait pas...
Autre question, doit-on essayer de remplacer certaines multiplications par des valeurs immédiates, par des additions/shift ?
Exemple :
Doit on réécrire ce code, ou bien le compilateur va-t-il faire quelque chose de très rapide ?Code:x = -x1+3*x2+28*x3-3*x4
Le compilateur fera ce qu'il faudra.