c'est valide et valable de faire ca en C ?

c'est valide et valable de faire ca en C ? - C++ - Programmation

Marsh Posté le 07-03-2003 à 14:29:55    

Code :
  1. if (type?type:(type=dbGetMosaicType(mosaicId)) == dbcSimpleMosaic)
  2. {
  3. [...]
  4. }


 
merci :)


Message édité par joce le 07-03-2003 à 14:32:27
Reply

Marsh Posté le 07-03-2003 à 14:29:55   

Reply

Marsh Posté le 07-03-2003 à 14:32:10    

valide, je sais pas, mais ignoble ca c sur :D

Reply

Marsh Posté le 07-03-2003 à 14:33:05    

chrisbk a écrit :

valide, je sais pas, mais ignoble ca c sur :D

ba ouais mais si je peux m'eviter de recalculer type je prefere le faire :D

Reply

Marsh Posté le 07-03-2003 à 14:44:50    

Alors c pas une légende, ce "joce au code immonde", il existe bien...
Apparement, c valide, mais si tu donnes pas l'algorithmique du truc, on risque pas de te dire si ça fait ce que tu veux.

Reply

Marsh Posté le 07-03-2003 à 14:47:37    

joce a écrit :

Code :
  1. if (type?type:(type=dbGetMosaicType(mosaicId)) == dbcSimpleMosaic)
  2. {
  3. [...]
  4. }


 
merci :)


ca me semble correct... mais moche

Reply

Marsh Posté le 07-03-2003 à 15:08:37    

c'est surtout le calcul que tu fais: meme si c'est du code dégeulasse, j'ai l'impression que la logique l'est aussi.
 
if (type ? type : ...
ben c'est sur que si type est != 0 ben type est aussi !=0
 
c'est pas mieux  
 
enfin je comprends pas trop ce que tu veux faire: j'ai l'imrpession que tu veux utilsier 0 comme valeur pour montrer que type n'as pas été calculé, mais à voire tes tests, j'ai l'impression que type peut valoir 0 meme apres calcul
 
ca serait pas plutot ?
 

Code :
  1. if(type==0)
  2. {
  3.   type=dbGetMosaicType(mosaicId);
  4. }
  6. if(type==dbcSimpleMosaic)
  7. {
  8.   // faire semblant de travailler
  9. }


 
si je suis ta logique et ton style ton code serait mieux en

Code :
  1. if(type || (type=dbGetMosaicType(mosaicId)) == dbcSimpleMosaic)))


et là y a effectivement une petite économie mais je comrpends toujours pas
 
 
 
EDIT: ouh honte à moi ou honte au code de Joce auxquel j'ai rien compris , je me suis bien fait avoir par 3 parentheses  :sol:  
 
enfin

Code :
  1. if(type==0)
  2. {
  3.   type=dbGetMosaicType(mosaicId);
  4. }
  6. if(type==dbcSimpleMosaic)
  7. {
  8.   // faire semblant de travailler
  9. }


est toujours valable.
 
mythe: l'opérateur ternaire est plus rapide que if.
 
je sais pas ou j'ai lu ça mais ça m'a paru vrai
 
"CPU cycles are cheap, but human cycles are very expensive"
 
je crois que preuve en ai fait


Message édité par Taz le 07-03-2003 à 15:27:54
Reply

Marsh Posté le 07-03-2003 à 15:22:16    

Je pense qu'il y a une erreur dans le code moche. Il voulait probablement faire ça plustot :

Code :
  1. if (type?type == dbcSimpleMosaic:(type=dbGetMosaicType(mosaicId)) == dbcSimpleMosaic)
  2.   {
  3.     [...]
  4.   }


Reply

Marsh Posté le 07-03-2003 à 16:03:14    

:pt1cable:
 
Je préfère le code de Taz :lol:

Reply

Marsh Posté le 07-03-2003 à 16:10:28    

ce qui est surtout interessant de voir c'est que un if et l'operateur ternaire génère le meme code assembleur.
 
autre mythe
 
if(i) est plus rapide que if(i!=0)
if(!i) est plus rapide que if(i==0)
 
le code est aussi le meme

Reply

Marsh Posté le 07-03-2003 à 16:24:38    

Mais il y a un truc que tu ne peux pas faire avec un if et que tu peux faire avec ?: c'est

Code :
  1. int a;
  2. int b;
  3. bool test;
  4. (test?a:b) = 5;


 
:D

Reply

Marsh Posté le 07-03-2003 à 16:24:38   

Reply

Marsh Posté le 07-03-2003 à 16:30:11    

Kristoph a écrit :

Mais il y a un truc que tu ne peux pas faire avec un if et que tu peux faire avec ?: c'est

Code :
  1. int a;
  2. int b;
  3. bool test;
  4. (test?a:b) = 5;


 
:D
 

pour peux que les operandes soit des lvalue et d'un type adequate. mais l'ISO C interdit cela. donc ce n'est pas valable


Message édité par Taz le 07-03-2003 à 16:33:21
Reply

Marsh Posté le 07-03-2003 à 17:09:36    

++Taz a écrit :

ce qui est surtout interessant de voir c'est que un if et l'operateur ternaire génère le meme code assembleur.
 
autre mythe
 
if(i) est plus rapide que if(i!=0)
if(!i) est plus rapide que if(i==0)
 
le code est aussi le meme


ça doit dépendre des compilateurs

Reply

Marsh Posté le 07-03-2003 à 17:12:36    

ben je vois pas comment un compilo peut se vautrer au point de générer 2 choses différents pour quelque chose d'aussi simple?


Message édité par Taz le 07-03-2003 à 17:12:44
Reply

Marsh Posté le 07-03-2003 à 18:12:48    

Un compilo de merde sans doute. Premier signe qu'il est temps d'en changer ...

Reply

Marsh Posté le 07-03-2003 à 19:43:38    

bon pour vous eclairer sur les raisons d'un tel truc infame, c'est :
 

Code :
  1. dbType type=NULL;
  4. if (pouet==machin && (type=dbGetMosaicType(mosaicId)) == dbcEmptyMosaic)
  5. {
  6.     [...]
  7. }
  9. if (truc==pipo || type?type:(type=dbGetMosaicType(mosaicId)) == dbcSimpleMosaic))
  10. {
  11.     if (toto)
  12.     {
  13.     [...]
  14.     if (type?type:(type=dbGetMosaicType(mosaicId)) == dbcSimpleMosaic)
  15.     {
  16.     [...]
  17.     }
  18.     [...]
  19.     }
  20. }


Message édité par joce le 07-03-2003 à 19:59:40
Reply

Marsh Posté le 07-03-2003 à 19:49:04    

tu te rends compte tous les efforts demandés tout ça par ce que tu fais tes affectations dans des tests, selon que l'évaluation est partielle ou complète. enfin si tu t'y retrouves.... Joce Coding Stailleu :sol:

Reply

Marsh Posté le 07-03-2003 à 19:55:04    

++Taz a écrit :

tu te rends compte tous les efforts demandés tout ça par ce que tu fais tes affectations dans des tests, selon que l'évaluation est partielle ou complète. enfin si tu t'y retrouves.... Joce Coding Stailleu :sol:  

Moi je le comprends, y a des cas ou tu préfères faire des affectations dans les tests, ca t'en évite par la suite.
Moi je comprends joce


---------------
http://runnerstats.net
Reply

Marsh Posté le 07-03-2003 à 19:57:53    

ben quand on fait ça, on fait juste un test simple, on va pas planquer son affectation derrier des ou et des et.

Reply

Marsh Posté le 07-03-2003 à 19:58:02    

ba sachant que dbGetMosaicType(mosaicId) bouffe quand même vachement de temps je préfère faire ca, mais honnétement je m'en passerait bien

Reply

Marsh Posté le 07-03-2003 à 20:00:50    

++Taz a écrit :

ben quand on fait ça, on fait juste un test simple, on va pas planquer son affectation derrier des ou et des et.

qu'est ce que t'entends par un test simple ?


Message édité par joce le 07-03-2003 à 20:00:59
Reply

Marsh Posté le 07-03-2003 à 20:01:18    

et t'as pas moyen de revoir un peu ton algo, c'est à dire utiliser type et l'initialiser que quand y en a besoin. tu veux à tout prix eviter. tu peux quand meme arriver a généraliser et à initialiser type une fois pour toutes au lieu de tester toutes les 3 lignes si c'est fait ou pas.

Reply

Marsh Posté le 07-03-2003 à 20:04:31    

joce a écrit :

qu'est ce que t'entends par un test simple ?

ben c'est admis de faire
 

Code :
  1. int c;
  3. while((c=fgetc(stdin)) != EOF)
  4. {}


 
par ce que là il est claire que l'affectation à lieu à chaque fois. si tu la retardes derriere des et et des ou, tu tombes sur le genre de problème que t'as. j'ai l'impression que t'es dans un cercle vicieux avec ton code. comme tu n'est jamais sur de ce qui a été fait précédemment, tu dois encore spéculer et tu affecte type si besoin, et le problème est les meme à l'étape suivante et ainsi de suite.
 

Reply

Marsh Posté le 07-03-2003 à 20:06:42    

ca reviendrait à faire :
 

Code :
  1. if (pouet==machin || !(truc==pipo) || (toto && truc==pipo))
  2. {
  3. type=dbGetMosaicType(mosaicId);
  4. }


 
c'est propre certe, mais niveau rapidité, ca donne quoi par rapport aux ? : ?

Reply

Marsh Posté le 07-03-2003 à 20:07:49    

++Taz a écrit :

ben c'est admis de faire
 

Code :
  1. int c;
  3. while((c=fgetc(stdin)) != EOF)
  4. {}


 
par ce que là il est claire que l'affectation à lieu à chaque fois. si tu la retardes derriere des et et des ou, tu tombes sur le genre de problème que t'as. j'ai l'impression que t'es dans un cercle vicieux avec ton code. comme tu n'est jamais sur de ce qui a été fait précédemment, tu dois encore spéculer et tu affecte type si besoin, et le problème est les meme à l'étape suivante et ainsi de suite.
 
 


ba y a des cas où on en a pas besoin du tout c'est tout, donc si je peux m'en passer, tant mieux :D


Message édité par joce le 07-03-2003 à 20:08:06
Reply

Marsh Posté le 07-03-2003 à 20:09:46    

!(truc==pipo)
 
=> (truc!=pipo)
 
 
et les et et ou sont bien plus rapides que des tests imbriqués. quand j'avais eu ce genre de problème, j'avais dessinés mes tests avec des arbres programmatiques (qui faisait des fois une page) et apres il apparait tres clairement ce qui est un ou  et ce qui est un et

Reply

Marsh Posté le 07-03-2003 à 20:12:14    

++Taz a écrit :

!(truc==pipo)
 
=> (truc!=pipo)
 


c'est uniquement pour la lisibilité ou y a un impact autre ?

Reply

Marsh Posté le 07-03-2003 à 20:17:13    

normalement non. pour tout ces genres de trucs, regardes les options de compilos pour voir le code asm générer. a moins que ton compilo soit infame, c'est strictement la meme chose.
 
edit: tu trouves plus lisible ! == que != ?  :heink:  
 
hummm, je commence à voir comment tu raisonnes :sweat:


Message édité par Taz le 07-03-2003 à 20:18:12
Reply

Marsh Posté le 07-03-2003 à 20:53:59    

++Taz a écrit :

normalement non. pour tout ces genres de trucs, regardes les options de compilos pour voir le code asm générer. a moins que ton compilo soit infame, c'est strictement la meme chose.
 
edit: tu trouves plus lisible ! == que != ?  :heink:  
 
hummm, je commence à voir comment tu raisonnes :sweat:  

nan j'ai pas dit ca, mais je me demandais pourquoi t'avais rectifié ce détail :D (j'avais mis une autre condition dans la parenthèse, que j'ai enlevée après, c'est pour ca que le ! était devant la parenthèse :))

Reply

Marsh Posté le 11-03-2003 à 17:04:00    

noldor a écrit :


ça doit dépendre des compilateurs


Ca dépends de rien du tout, si tu regardes un peu l'ASM, tu veras que le compilo est obligé de générer le même code, c'est à dire un jnz ou un jz.

Reply

Marsh Posté le 21-03-2003 à 06:44:25    

En le déroulant, et en espérant que je ne me trompe pas:

Code :
  1. dbType type=NULL;
  3. if (pouet==machin){
  4. type=dbGetMosaicType(mosaicId);
  5. if(type== dbcEmptyMosaic){
  6.  //...
  7. }
  8. }
  10. bool doit= false;
  11. if (truc==pipo)
  12. doit= true;
  13. else{
  14. if(!type)
  15.  type=dbGetMosaicType(mosaicId);
  16. if(type==dbcSimpleMosaic)
  17.  doit= true;
  18. }
  20. if(doit && toto){
  21. //...
  22. if(!type)
  23.  type=dbGetMosaicType(mosaicId);
  24. if(type==dbcSimpleMosaic){
  25.  //...
  26. }
  27. //...
  28. }


 
 
Mais c'est plus simple en factorisant dans une macro:

Code :
  1. //ne donne sa valeur à "type" que si on l'utilise
  2. #define LATETYPE (type?type:(type=dbGetMosaicType(mosaicId))
  4. dbType type=NULL;
  6. if (pouet==machin && LATETYPE==dbcEmptyMosaic){
  7. //...
  8. }
  10. if (truc==pipo || LATETYPE == dbcSimpleMosaic)){
  11. if (toto){
  12.  //...
  13.  if (LATETYPE==dbcSimpleMosaic){
  14.   //...
  15.  }
  16.  //...
  17. }
  18. }

Une macro c'est pas beau, mais ici c'est encore plus moche si on ne l'utilise pas.
 
 
On peut même améliorer la dernière partie:

Code :
  1. if (toto && (truc==pipo || LATETYPE == dbcSimpleMosaic)) ){
  2. //...
  3. if (LATETYPE==dbcSimpleMosaic){
  4.  //...
  5. }
  6. //...
  7. }


(je croise les doigts, j'ai rien testé)
 
Si tu serais en C++, ben tu pourrais cacher l'évaluation retardée dans une classe.


---------------
Bricocheap: Montage de ventilo sur paté de mastic silicone
Reply

Marsh Posté le 21-03-2003 à 07:20:20    

t'as recommencé    [:klemix]

Reply

Marsh Posté le 22-03-2003 à 08:10:19    

Quoi ? Les macros ?
 
C'est pas moi qui l'utilise, c'est pour joce... :ange:


---------------
Bricocheap: Montage de ventilo sur paté de mastic silicone
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed