est ce que je sais encore programmer en C ? - Page 1

-

tu peux faire:
while (FadePalOut(BG_PALETTE) | FadePalOut(BG_PALETTE_SUB) | FadePalOut(SPRITE_PALETTE)) swiWaitForVBlank();
Mais je ne comprend vraiment pas comment un compilateur peut faire ca...

Yop,

C'est tout a fait normal qu'il evalue chaque expression, mais y a petit probleme de logique au niveau de l'evaluation.
#include <stdio.h> int fonction1(int a) {      if (a & 1)           return 1;      else           return 0; } int fonction2(int a) {      if ((a*10) == 10 )           return 1;      else           return 0; } void main(void) {      int nombre;      do      {           printf("Entre un nombre :\n");           fflush(stdin);           scanf("%d",&nombre);      } while( fonction1(nombre) && fonction2(nombre));       }

Donc ici, si tu tapes 1 les deux conditions seront vraies et la boucle se reiterera tandis que si tu saisis 3 la premiere evaluation sera validee mais pas la seconde et donc le programme continuera en sequence et se fermera.

En gros dis toi qu'un compilateur evalue toutes les expressions precedent ou suivant un &&. Si le compilateur reconnait un || alors il n'evaluera qu'une seule expression en general celle qui precede un ||.


Table de verite ET
0 0 0
0 1 0
1 0 0
1 1 1

Table de verite OU
0 0 0
0 1 1
1 0 1
1 1 1

On voit bien ici que pour la ET on

-

Yop,

C'est tout a fait normal qu'il evalue chaque expression, mais y a petit probleme de logique au niveau de l'evaluation.
#include <stdio.h> int fonction1(int a) {      if (a & 1)           return 1;      else           return 0; } int fonction2(int a) {      if ((a*10) == 10 )           return 1;      else           return 0; } void main(void) {      int nombre;      do      {           printf("Entre un nombre :\n");           fflush(stdin);           scanf("%d",&nombre);      } while( fonction1(nombre) && fonction2(nombre));       }

Donc ici, si tu tapes 1 les deux conditions seront vraies et la boucle se reiterera tandis que si tu saisis 3 la premiere evaluation sera validee mais pas la seconde et donc le programme continuera en sequence et se fermera.

En gros dis toi qu'un compilateur evalue toutes les expressions precedent ou suivant un &&. Si le compilateur reconnait un || alors il n'evaluera qu'une seule expression en general celle qui precede un ||.


Table de verite ET
0 0 0
0 1 0
1 0 0
1 1 1

Table de verite OU
0 0 0
0 1 1
1 0 1
1 1 1

Merde j'ai valide deux fois la meme chose.... Je suis pas reveille mdr

-

oue voila

lol j avais mal compris moi. #loose#
sinon pour mon exemple il faut revoire la grammaire du C pour l'ordonnancement de l'operation, mais bon je suis pas sur que tu en ais vraiment besoin.

orion> c'est ce qui s'appele l'évaluation paresseuse
j'utilise ça souvent, genre if(p!=NULL && truc(p)==machin)

C'est loin d'être un bug, c'est même imposé par les standards C il me semble.
Enfin tous les compilo C et la grande majorité des autres langagues fonctionnent comme cela.

C'est même pratique dans le cas cité par Nu. Par contre ça permet aussi des horreurs(donc j'adore ) du style:
mafonction(truc) || printf("Erreur: mafonction retourne 0");

Uther
: C'est loin d'être un bug, c'est même imposé par les standards C il me semble.

Tout à fait.

Enfin tous les compilo C et la grande majorité des autres langagues fonctionnent comme cela.

Oui, mais pas le VB par exemple

C'est même pratique dans le cas cité par Nu. Par contre ça permet aussi des horreurs(donc j'adore ) du style:
mafonction(truc) || printf("Erreur: mafonction retourne 0");

Oui, mais ce genre de code s'utilise très souvent en PHP. Je ne vois pas trop le problème ?

c'est quand même super pas clair comme écriture !
et l'écrire avec un if ne prend pas plus de place (et le code généré sera surement le même)

Si, c'est vraiment bien plus fréquent qu'on pourrait le croire... rechercher_bidule(nom_du_bidule) || ajouter_bidule(nom_du_bidule,description), etc... Cela dit, c'est vrai que c'est un peu moche de faire ça si c'est pour ignorer la valeur de retour de l'expression à droite de ||, un if est plus adapté

c'est tres "bash" comme écriture ^^

bah oui, mais dans certains types de programmes où tu dois tout le tps faire ce genre de choses c'est nettement plus lisible d'écrire ça de façon compacte comme ça que d'imbriquer des centaines de if...

Sasume :

Enfin tous les compilo C et la grande majorité des autres langagues fonctionnent comme cela.

Oui, mais pas le VB par exemple

Je parlais de langague de programation, pas de VB

Sasume :

C'est même pratique dans le cas cité par Nu. Par contre ça permet aussi des horreurs(donc j'adore ) du style:
mafonction(truc) || printf("Erreur: mafonction retourne 0");

Oui, mais ce genre de code s'utilise très souvent en PHP. Je ne vois pas trop le problème ?

En PHP ou bash c'est un pratique courrante, donc pas vraiment génant. En C ca l'est beaucoup moins.

Personellement pour l'exemple que j'ai donné je trouve bien plus clair comme ça qu'avec un if. Le code de fonctionnement normal est aligné avec le reste : ça s'identifie en un coup d'oeil contairement au if qui introduit une cassure dans l'apparence linéraire du code.
Mais on m'a souvent reproché que c'était crade comme écriture.

Enfin là, j'ai donné un exemple facile à faire et à comprendre mais parfois je l'utilise pour faire des truc bien plus tordus avec plein de || et de &&.

Orion> oui, bah de meme que si tu fais (expr1 && expr2) la derniere ne sera pas evaluee a partir du moment ou la premiere est fausse...
c'est tres logique hein, ca releve du bon sens... avec les && il suffit qu'il y en aie une de FALSE pour que le resultat global soit FALSE, quel que soit le resultat de chaque autre expression, donc des que t'en a une de fausse dans la liste, ca ne sert strictement a rien de tester les autres. idem pour les ||, dans l'autre sens.. a partir du moment ou un seul est vrai, le resultat global est vrai, peu importe le resultat individuel de celles qui reste...

vois un

if (pwet && plop && ouga)
  tagada(tsointsoin);

if (pouet || marmotte || bouga)
  tagada(tsointsoin);

comme un

if (pwet)
  if (plop)
    if (ouga)
      {
        tagada(tsointsoin);
      }

if (pouet)
  tagada(tsointsoin);
else if (marmotte)
  tagada(tsointsoin);
else if (bouga)
  tagada(tsointsoin);

a partir du moment ou un des "if" est faux, le code dans le bloc du if (donc les autres ifs) est ignore
a partir du moment ou un des "if" est vrai, le else est ignore... meme principe...

Très bel exemple

-

tiens en fait aujourd hui en repensant a ce topic j en ai profiter pour le mettre en application dans un script perl:

sub ParseScript()
  {
    while( <IN> )
      {
	$line++;

	( /^\s+$/ || /#.+/)  
        || (/\s*SET\s+PROTOCOL\s+([0-9]+)/)           &&  SISTCommand("3",$1)
	|| (/\s*RESET/)                               &&  FSISTCommand("4",$1)
	|| (/\s*MEMORY\s+RANGE\s+([0-9]+)/)           &&  SISTCommand("0B",$1)
	|| (/\s*POLL\s+([0-9]+)/)                     &&  SISTCommand("16",$1)
	|| (/\s*WRITE\s+WORD\s+([0-9]+)/)             &&  SISTCommand("17",$1)
	|| (/\s*LATCH\s+HIGH\s+DATA\s+([0-9]+)/)      &&  SISTCommand("18",$1)
	|| (/\s*LATCH\s+LOW\s+ADDRESS\s+([0-9]+)/)    &&  SISTCommand("19",$1)
	|| (/\s*LATCH\s+HIGH\s+ADDRESS\s+([0-9]+)/)   &&  SISTCommand("1A",$1)
	|| (/\s*SET\s+BYTE\s+([0-9]+)/)               &&  SISTCommand("1B",$1)
	|| (/\s*READ\s+BYTE\s+([0-9]+)/)              &&  SISTCommand("1C",$1)
	|| (/\s*JUMP\s+AND\s+EXECUTE\s+([0-9]+)/)     &&  SISTCommand("1F",$1)

      }
  }

Ca arend le code plus lisible (nb dans ce cas la j aurai pus faire un tableau etc... mais bon ca n aurai pas marche pour la suite

En C, un truc pour lequel on utilise pas mal cette notation, c'estpour contrôler des pointeurs et des valeurs pointées

int MaFonction(int *pt_i)
{
if(pt_i==NULL || *pt_i<0)
	return -1;// Les valeurs sont invalides

(*pt_i)++;
return 0;
}

Ici, si pt_i est NULL, le programme ne regardera pas la valeur pointée.

Link :
En C, un truc pour lequel on utilise pas mal cette notation, c'estpour contrôler des pointeurs et des valeurs pointées

int MaFonction(int *pt_i)
{
if(pt_i==NULL || *pt_i<0)
	return -1;// Les valeurs sont invalides

(*pt_i)++;
return 0;
}

Ici, si pt_i est NULL, le programme ne regardera pas la valeur pointée.

Oue sauf que le pt_i == NULL est un peu de trop. Enfin il aurait ete tout aussi simple de nier ton pointeur ainsi: !pt_i ca serait revenu au meme. (cf la table du not ;o))

[...] Et j'y repense vu que ta variable est un int tu peux utiliser le fait que le bit de poids fort est en fait un bit de signe...

+++

Et j'y repense vu que ta variable est un int tu peux utiliser le fait que le bit de poids fort est en fait un bit de signe...

Sauf que c'est au contraire nettement plus simple pour le processeur de tester le signe d'une variable que de tester un bit arbitraire Après, c'est possible qu'un compilo optimise "if (x&0x8000)" en "if (x<0)", mais sinon c'est de loin la deuxième version qui sera la plus rapide...


Pour ce qui est de ==NULL, c'est vraiment une question de style, ça n'a aucune influence sur le code généré... (égout, couleuvres, toussa )

Certe tout depend de l'archi sur laquelle on programme mais un test de bit est tjrs plus rapide qu'une comparaison.

Pour moi un AND [var],80000000h jz blabla est tjrs plus rapide qu'un CMP dword ptr
[var],0 jb blabla ou jl blabla. (Dans l'un il fait une soustraction l'autre non).

Le NULL c'est le meme principe que pour le AND au niveau de la prediction des mnemoniques d'assemblages qui sera moins judicieuse sur certains compilateurs.

ah oui on est pas sur le forum 68k, donc c'est peut-être vrai sur certaines vieilles architectures (encore que, bcp de processeurs ont une instruction de comparaison avec zéro, qui risque d'être plus rapide qu'une comparaison avec un nombre quelconque, et éventuellement plus rapide qu'une instruction de test de bit, puisqu'il y a une seule opérande donc éventuellement moins de données à lire en mémoire)

et pour ce qui est de ==NULL, faut pas pousser mémé dans les orties, si un compilateur n'est pas capable d'optimiser if (x==0) en if (x) si la deuxième version est plus efficace, il risque pas d'être capable d'optimiser grand-chose (surtout qu'on ne peut pas tjs éviter de mentionner le 0, par exemple if (x>0) n'a pas d'équivalent sans 0)

Pense ce que tu veux... J'ai pas le temps de polémiquer.

pour la compatibilité il vaut mieux garder le == NULL, des fois que NULL != 0 ...

Et ça arrive souvent ?

non mais on sait jamais