Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1709 connectés 

  FORUM HardWare.fr
  Programmation
  C++

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

 
 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

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

n°325988
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2003 à 14:29:55  profilanswer
 

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


 
merci :)


Message édité par joce le 07-03-2003 à 14:32:27
mood
Publicité
Posté le 07-03-2003 à 14:29:55  profilanswer
 

n°325993
chrisbk
-
Posté le 07-03-2003 à 14:32:10  profilanswer
 

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

n°325995
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2003 à 14:33:05  profilanswer
 

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

n°326015
El_gringo
Posté le 07-03-2003 à 14:44:50  profilanswer
 

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.

n°326020
lorill
Posté le 07-03-2003 à 14:47:37  profilanswer
 

joce a écrit :

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


 
merci :)


ca me semble correct... mais moche

n°326046
Taz
bisounours-codeur
Posté le 07-03-2003 à 15:08:37  profilanswer
 

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
n°326070
Kristoph
Posté le 07-03-2003 à 15:22:16  profilanswer
 

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.   }


n°326118
MagicBuzz
Posté le 07-03-2003 à 16:03:14  profilanswer
 

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

n°326128
Taz
bisounours-codeur
Posté le 07-03-2003 à 16:10:28  profilanswer
 

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

n°326145
Kristoph
Posté le 07-03-2003 à 16:24:38  profilanswer
 

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

mood
Publicité
Posté le 07-03-2003 à 16:24:38  profilanswer
 

n°326155
Taz
bisounours-codeur
Posté le 07-03-2003 à 16:30:11  profilanswer
 

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
n°326196
noldor
Rockn'roll
Posté le 07-03-2003 à 17:09:36  profilanswer
 

++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

n°326197
Taz
bisounours-codeur
Posté le 07-03-2003 à 17:12:36  profilanswer
 

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
n°326264
Kristoph
Posté le 07-03-2003 à 18:12:48  profilanswer
 

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

n°326313
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2003 à 19:43:38  profilanswer
 

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
n°326317
Taz
bisounours-codeur
Posté le 07-03-2003 à 19:49:04  profilanswer
 

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:

n°326319
noldor
Rockn'roll
Posté le 07-03-2003 à 19:55:04  profilanswer
 

++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
n°326322
Taz
bisounours-codeur
Posté le 07-03-2003 à 19:57:53  profilanswer
 

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

n°326323
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2003 à 19:58:02  profilanswer
 

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

n°326328
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2003 à 20:00:50  profilanswer
 

++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
n°326329
Taz
bisounours-codeur
Posté le 07-03-2003 à 20:01:18  profilanswer
 

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.

n°326334
Taz
bisounours-codeur
Posté le 07-03-2003 à 20:04:31  profilanswer
 

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.
 

n°326336
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2003 à 20:06:42  profilanswer
 

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 ? : ?

n°326337
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2003 à 20:07:49  profilanswer
 

++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
n°326338
Taz
bisounours-codeur
Posté le 07-03-2003 à 20:09:46  profilanswer
 

!(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

n°326341
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2003 à 20:12:14  profilanswer
 

++Taz a écrit :

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


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

n°326345
Taz
bisounours-codeur
Posté le 07-03-2003 à 20:17:13  profilanswer
 

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
n°326368
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2003 à 20:53:59  profilanswer
 

++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 :))

n°329688
MagicBuzz
Posté le 11-03-2003 à 17:04:00  profilanswer
 

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.

n°339314
Musaran
Cerveaulté
Posté le 21-03-2003 à 06:44:25  profilanswer
 

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
n°339323
Taz
bisounours-codeur
Posté le 21-03-2003 à 07:20:20  profilanswer
 

t'as recommencé    [:klemix]

n°340304
Musaran
Cerveaulté
Posté le 22-03-2003 à 08:10:19  profilanswer
 

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


---------------
Bricocheap: Montage de ventilo sur paté de mastic silicone
mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C++

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

 

Sujets relatifs
XML : est ce un Schema Valide?XML: c'est valable plusieurs noeuds enfants de même nom?
verifier si lien valideExpression: BLOC_TYPE_IS_VALIDE????
Savoir si la valeur renvoyée par mysql_query() est valide?Script de E-commerce ? J'en trouve aucun de valable
[W3C] pk ca valide pas ca?[php] verifier qu une e mail est valide
[XML]pourquoi ma DTD n'est-elle pas valide????[Access - Graphik et Requete] J'arrive pas a trouver un titre valable
Plus de sujets relatifs à : c'est valide et valable de faire ca en C ?

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo
Page générée en 0.122 secondes

Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR