Extraire une information d'une variable dans un menu pour effectuer une action

**rm_78** · 09/04/2022, 19h14

Bonjour,
je suis débutant en c++ et j'aimerais extraire une valeur que j'ai mise dans une variable "numéro" où on peut choisir le numéro 1, 2 ou 3 grâce à un bouton poussoir.
Je fais valider le choix dans un deuxième menu de l'écran LCD à l'aide d'un autre bouton poussoir.
Le problème étant que je voudrais prendre le chiffre dans la variable "numéro" donc soit 1,2, 3 une fois qu'il a été validé et faire allumer 1 LED différente en fonction du numéro.

Je ne sais pas si cela est comprensible car moi je travaille dessus mais j'aimerais bien de l'aide.
merci

voici un bout du code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
case 1:
// message pour selectionner
    lcd.setCursor(0,0);    
    lcd.print("Selectionner un");
    lcd.setCursor(0,1);
    lcd.print("numero:");
    lcd.setCursor(9,1);
   {numero ++;}
   delay(100);
 
 //permet de ne pas dépasser 3 
  if(numero >3)
     {numero =1;}
     {lcd.print(numero);}
    break;
 
  case 2:
//message validation 
    lcd.setCursor(0, 0);
    lcd.print("vous avez fais");
    lcd.setCursor(0, 1);
    lcd.print("le choix:");
    lcd.setCursor(14, 1);
    lcd.print(numero);
   break;}
 
// partie qui ne fonctionne pas  
if(numero =1)
   {digitalWrite(led1, HIGH);}
 
 if(numero  =2)
   {digitalWrite(led2,HIGH);}
 
 if(numero =3)
   {digitalWrite(led3, HIGH);} 
 
 
  }

**Jerome Briot** · 10/04/2022, 06h59

Tu trouveras toutes les informations utiles ici : https://c.developpez.com/faq/?page=Les-operateurs

**Kinesra** · 10/04/2022, 10h29

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
if(numero =1)
   {digitalWrite(led1, HIGH);}

moi, je mettrais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if (numero == 1)
{ digitalWrite(led1, HIGH);}

**Jay M** · 10/04/2022, 11h51

et pareil pour les autres

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
// partie qui ne fonctionne pas  
if(numero =1)
   {digitalWrite(led1, HIGH);}
 
 if(numero  =2)
   {digitalWrite(led2,HIGH);}
 
 if(numero =3)
   {digitalWrite(led3, HIGH);}

= c'est pour l'affectation d'une valeur, == c'est pour tester l'égalité

utiliser un tableau pourrait simplifier pas mal les choses

**rm_78** · 10/04/2022, 18h11

Merci beaucoup ça fonctionne !! c'est souvent sur des erreurs bêtes qu'on reste bloqué.
J'ai une autre petite question comment on avance d'un menu automatiquement à partir d'un "delay" . En mode afficher le menu 1 pendant 2 seconde et passer au menu 2.

**Guesset** · 11/04/2022, 10h12

Bonjour,

Les tests sur numero == 1, 2, 3 pourraient être enchaînés par des "else". Ca ne sert à rien de tester si numero == 3 alors que le test numero == 1 c'est avéré positif.

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
if(numero == 1)
   digitalWrite(led1, HIGH);
else if(numero  == 2)
   digitalWrite(led2,HIGH);
else if(numero == 3)
   digitalWrite(led3, HIGH);

Si le nombre de cas était plus important, on préférerait une logique de test arborescente car le nombre moyen de tests (hypothèse d'une équipartition des 3 cas) est alors en log2(n) contre n/2 si ils sont mis à la queue leu leu. Dans notre cas ce n'est pas intéressant : 1.58 contre 1.5.
Dans ce cas on préférera peut être écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
switch(numero) {
   case 1 : digitalWrite(led1, HIGH); break;
   case 2 : digitalWrite(led2, HIGH); break;
   case 3 : digitalWrite(led3, HIGH);
}

Salutations

**Jay M** · 11/04/2022, 13h26

Envoyé par rm_78

J'ai une autre petite question comment on avance d'un menu automatiquement à partir d'un "delay" . En mode afficher le menu 1 pendant 2 seconde et passer au menu 2.

ça nécessite de repenser le code en une machine a état qui gère à la fois les évènements utilisateurs ainsi que le temps.

**Kinesra** · 12/04/2022, 10h26

= c'est pour l'affectation d'une valeur, == c'est pour tester l'égalité

Oui justement. Ca dépend de ce qu'on veut faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (numero=1)

ce code affecte la valeur 1 à la variable 'numero' et l'expression numero=1 retourne TRUE (en C, tout ce qui n'est pas 0 est VRAI. Ici, le if est donc toujours VRAI tant qu'une valeur non nul est affectée à 'numero').

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (numero == 1)

ce code retourne TRUE si la valeur de 'numero' est 1, FALSE sinon.

**Guesset** · 12/04/2022, 20h03

Bonjour Kinesra,

Envoyé par Kinesra

...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (numero == 1)

ce code retourne TRUE si la valeur de 'numero' est 1, FALSE sinon.

C'est un abus de langage assez fréquent. En fait, il n'y a pas de valeur booléenne de retour. Ce code génère une comparaison à 1 (par exemple cmp eax, 1) suivi d'un saut conditionnel si non égal (équivalent du else même vide) (par exemple jne Label_else jump if non equal).
C'est vrai que cela se comporte comme s'il y avait une variable booléenne mais ...

Une expression numérique ou booléenne (i.e. sans opérateur de comparaison explicite) est comparée à 0. Le "then" est en séquence et le "else" correspond à un jz ou un je. Cest pourquoi on peut aussi écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (numero)

Salut

**Jay M** · 12/04/2022, 11h32

Oui justement. Ca dépend de ce qu'on veut faire

on n'a généralement pas envie de faire cela avec des constantes... encore moins en enchaînant des if....

**Jay M** · 12/04/2022, 20h18

Je ne dirais pas que c'est un abus de langage, ça dépend où on se place

La spécification du if en C++ c'est (en simplifiant)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (condition) statement-true

et la norme dit que condition est une "expression which is contextually convertible to bool"

Ici l'expression en question qui forme la condition est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(numero == 1)

.
Comme on utilise ==, on a bien un opérateur de comparaison qui fait partie de la liste des expressions correspondant à la définition et qui retourne true ou false suivant l'égalité

Donc d'un point de vue interprétation syntaxique

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(numero == 1)

est bien une valeur de vérité, un bool. c'est cette valeur qui est passée au if.

Ensuite bien sûr le compilateur est smart et pour des cas simple comme celui ci génère du code optimisé et utilisera la meilleure opération en assembleur

**Guesset** · 13/04/2022, 11h36

Bonjour,

Aucun compilateur, smart ou pas, ne passera par la création d'une variable booléenne dans un if ou autre test de branchement. "Convertible" ne signifie pas convertie. Hors d'un if (ou d'un test avec branchement conditionnel comme while(), for(), ? ) l'expression booléenne peut être effectivement convertie en variable temporaire booléenne, par exemple dans une affectation.

Ce qu'il faut comprendre, c'est que la comparaison qui permettrait de créer ladite variable booléenne donne directement l'information (flags) de saut conditionnel vers "else" (même vide). Il n'y a donc aucune utilité à passer par une variable booléenne. C'est la limite du raisonnement analytique : ne pas produire plus d'éléments qu'il n'en existe.

Si une variable booléenne cachée existait if(i < 5) se traduirait comme if(bool(i < 5) == true) ce qui n'est jamais le cas même toutes optimisations supprimées. Par curiosité (certainement malsaine

) j'incite à regarder une grammaire de compilateur.

En dehors d'une expression booléenne, avec par exemple une simple variable (booléenne ou non) ou une expression arithmétique (laissons de côté les flottants qui peuvent poser de nombreux problèmes dans ce type d'usage) le compilateur fait une comparaison à 0 pour décider directement du branchement à faire. Il n'y a pas de conversion. Par exemple, si l'expression E est un non signé en 64 bits le compilateur fera une comparaison du même type que E != 0ULL.

Pour avoir une chance (???) de faire apparaître une variable booléenne temporaire, il faudrait une expression logique complexe dans un test de branchement avec désactivation de l'évaluation courte. Et encore...

Si cela peut aider d'imaginer une variable booléenne virtuelle, pourquoi pas ? Mais cela simplifie la compréhension sans correspondre à la réalité.

Est-ce important ? Oui et non. Oui si on veut pressentir la complexité du code engendré sans aller voir l'assembleur. Non, pour savoir que le code fonctionne ou pas.

Bon, c'était mon quart d'heure de coupeur de cheveux en 4 (longitudinalement bien sûr

)

Salutations

**Jay M** · 13/04/2022, 20h26

je crois qu'on dit la même chose.

- La norme dit que l'expression doit s'évaluer en tant qu'un bool ou comparable et que le branchement s'effectue en fonction de cette valeur de vérité.
- Le compilateur, pour des cas simples se passe du booléen. il est virtuel

Quand je dis que c'est pour les cas simples, c'est quand le compilateur reconnait le test et qu'il y a une instruction en langage machine qui fait le job mais dans des cas plus compliqués il faut bien passer par un booléen intermédiaire

cas évident où c'est nécessaire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
bool coucou() {
 return random(0, 101) < 30; 
} 
 
void loop() {
  if (coucou()) {
     ...
  } 
}

cas moins évident, sur un UNO:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
unsigned long toto = 0xFF00FF00 + random(0, 5);
if (toto == 0xFF00FF00) {
  ...
}

ici on a affaire à une comparaison sur un unsigned long et le processeur étant 8 bit il ne sait pas faire cela d'un coup... donc il va faire une opération pour le savoir et tester le booléen résultat pour décider de rentrer ou non dans le if

**Guesset** · 13/04/2022, 23h18

Bonsoir,

La norme ne dit pas que l'expression soit convertie en booléen mais qu'elle soit convertible. C'est un potentiel qui garantit une aptitude de levée de doute pour le test et non un besoin de conversion explicite. Par exemple, un flottant NaN laisse une ambiguïté élevée qui ne satisfait pas a priori au critère de convertibilité.

C'est la raison pour laquelle l'usage de la fonction coucou, même en inline, sera moins efficace que if (random(0, 101) < 30) { ... }. En effet coucou() force le passage par une évaluation booléenne inutile. Le code initial revient à écrire (en supposant un inline) : if (bool(random(0, 101) < 30) == true) { ... }. Il va falloir pousser loin les curseurs d'optimisation et croiser les doigts pour espérer que le compilateur corrige cela.

Un if a toujours besoin d'une comparaison pour déclencher son saut conditionnel. Si elle est absente, il opère une comparaison == 0 y compris pour un booléen. En effet pour faire un saut conditionnel il faut évaluer une condition qui va prépositionner les flags pour que le saut ait lieu ou pas. C'est dans le choix des flags du saut conditionnel que se trouverait la variable booléenne virtuelle.

Le deuxième exemple utilisera le fait qu'une comparaison n'est qu'une soustraction dont on n'utilise pas le résultat mais seulement les flags. Pour dépasser la taille native d'un CPU on utilisera une soustraction avec retenue (ou une comparaison avec retenue si elle existe) répétée 4 fois sur les différents octets des 32 bits. Puis le saut conditionnel aura lieu en tenant compte des flags résultants (les mêmes qui seraient utiles si on avait besoin d'un variable booléenne).

L'opérateur de comparaison utilisé par le if associe intimement une comparaison asm (soustraction sans valeur de destination) et la prise en compte de différents flags (selon l'opérateur de comparaison souhaité) au sein même du saut conditionnel (jcc). C'est cette intrication qui rend au mieux virtuelle toute variable booléenne intermédiaire.

On peut faire abstraction du fonctionnement réel des compilateurs et écrire sans état d'âme "si c'est vrai..." mais il est alors préférable de ne pas faire référence à une hypothétique variable intermédiaire qui serait générée par le compilateur. C'est tout l'objet de ma remarque initiale.

Un détail pour la route. Le saut conditionnel se branche après la fin du bloc "then" c'est à dire au début du bloc "else" s'il existe. Les flags utilisés représentent donc une condition inverse de celle écrite en code source (par exemple jne- jump if non equal - pour un "==".

Un exemple pour essayer d'illustrer : Si le seau déborde je me mouille les pieds. Cette phrase ne nécessite pas d'être réécrite ainsi : Est-ce que le seau déborde ? Si oui je me mouille les pieds.

Je vais me sécher.

Salutations

**Jay M** · 14/04/2022, 15h42

OK - c'est un peu un dialogue de sourds parce qu'on est d'accord sur le fond.

Je dis qu'il existe des cas où le compilo va devoir tester un booléen parce qu'il n'a pas le choix. est-ce moins efficace, sans doute, mais c'est le cas car vous aurez choisi une fonction un peu plus compliquée que mon coucou() par exemple.

sinon quand il peut s'en passer bien sûr qu'il va le faire et le bool est effectivement tout à fait virtuel

**Guesset** · 15/04/2022, 10h57

Bonjour,

Bien sûr que nous sommes d'accord sur les mécanismes mais pas sur l'ordre. Un compilateur intelligent ne va pas générer du code inutile pour ensuite tenter de le retirer.

Les CPU ne savent pas directement travailler sur des booléens, les branchements conditionnels sont essentiellement sur des comparaisons de valeurs (il y a aussi des sauts sur overflow, parity etc mais il faut une comparaison préalable pour alimenter les flags). Le compilateur ne va donc pas, a priori, générer un booléen sur la base d'une comparaison arithmétique pour ensuite être obligé de faire une seconde comparaison à 0 pour faire le saut en tenant compte du booléen alors que le saut direct sur la comparaison initiale est toujours possible. Le saut conditionnel direct est le booléen virtuel.

Les évaluations abrégées (actives par défaut) transforment les expressions complexes en une imbrication de tests élémentaires.

Il y a des cas où le compilateur n'a pas besoin de générer une comparaison car l'opération génère les flags attendus. Par exemple, if(a-b) n'a pas besoin d'être transformé en if(a-b != 0) car a-b va directement générer le positionnement du flag de zéro. Si le compilateur est un peut sophistiqué, il économisera l'instruction de comparaison à 0. D'un autre coté, écrire if(a-b) au lieu de if(a != b) n'est peut être pas à l'honneur du développeur.

Il est bien possible, si je fouille un peu, que j'ai écrit des horreurs pareils. Mais je ne vais pas fouiller.

Salutations

**Jay M** · 15/04/2022, 12h33

Envoyé par Guesset

Un compilateur intelligent ne va pas générer du code inutile pour ensuite tenter de le retirer.

les phases (parfois théoriques je suis d'accord) d'un compilateur sont résumées ici

Nom : hdonL.jpg
Affichages : 217
Taille : 354,0 Ko

mais l'optimiser peut intervenir à différents moments

- par exemple le code des fonctions inutilisées est viré au link et d'autres optimisations peuvent être aussi décidées à ce moment
- regardez comment fonctionne LLVM

**Guesset** · 15/04/2022, 16h36

Bonjour,

C'est le schéma classique. Il ne suppose pas que les phases amont de l'optimisation soient traitées sans réflexion sous prétexte qu'il y a l'optimisation. Or pour créer une variable booléenne intermédiaire il faut plus de code : pratiquement le code cible plus celui de la création de la variable booléenne et celui son utilisation par une comparaison à 0 pour opérer le saut attendu.

Exemple débile mais avec un code simple :

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

if(i > 7) i--; else i++; // on suppose i dans eax et la variable booléenne dans ecx

Deux implémentations assembleur non optimales possibles

Code ASM :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
; Code direct
   cmp eax, 7
   jng @else         ; jump if not greater : i <= 7
   dec eax
   jmp @end_if
@else:
   inc eax
@end_if
 
; Code avec variable booléenne
   cmp eax, 7
   setg ecx          ; création de la variable booléenne = eax > 7 ? 1 : 0 
   cmp ecx, 0        ; utilisation de la variable booléenne
   jng  @else        ; Saut si ecx !> 0 <=>  ecx <= 0, mais comme ecx = 0 ou 1 <=> exc == 0 soit jz
   dec eax
   jmp @end_if
@else:
   inc eax
@end_if

On voit bien (d'autant que j'ai mis jng ligne 14 là où jz aurait été plus lisible

) que les deux lignes 12 et 13 consacrées à la variable booléenne peuvent allègrement disparaître, ou mieux ne pas être crées, sans complexifier aucunement le code donc à la portée d'un compilo simplet. J'y arrive bien moi !

LLVM a beaucoup de succès par la souplesse qu'il apporte tout en gardant des performances correctes. Ce n'est cependant pas mon premier choix.

Salutations

**Jay M** · 15/04/2022, 18h22

on est bien d'accord - et il existe des cas particuliers. Quand le compilo peut se passer du booléen, il le fait - soit directement, soit à l'étape d'optimisation suivant les technologies et l'arbre de décision.

Oui pour LLVM. GCC par exemple est plus répandu que CLANG / LLVM mais si on veut aller plus vite et moins consommer ou intégrer cela dans une toolchain, CLANG sera sans doute plus efficient

Extraire une information d'une variable dans un menu pour effectuer une action

Arduino

Vue hybride

Discussions similaires

Partager

Partager