Discussion :

[debuteenc]

Bonsoir,
J'ai codé cette fonction et elle me retourne toujours true (1) quelque soit le caractère entré...
Auriez-vous l'amabilité de m'indiquer ce qui cloche?
Merci et bonne soirée

J-P

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
bool couleur_valide(char c)
{
    if (c == '.' or c == 'R' or c == 'G' or c == 'B' or c =='C' or c == 'Y' or c == 'M')
    {
        bool couleur_valide = true;
    }
    else
    {
        bool couleur_valide = false;
    }
 
    cout<<c<<endl;
    cout<<couleur_valide<<endl;
}

[Bousk]

- or au lieu de ||, c'est pas commun mais admettons
- fonction bool qui retourne rien
- variable qui porte le nom de la fonction
> et dont la portée est ridicule
> ce qui la rend inutile
Ce machin compile quelque part ? Faudrait voir à pas ignorer les warning.

[debuteenc]

Bonsoir,

Je n'ai pas mis la variable retournée. Du moment que j'affiche la variable c et le booléen...
Pour les or à la place des ||, c'est une déformation iussue de 40 années d'assembleur...

Ça compile sans problème...et c'est bien là mon souci...
Manifestement ma fonction contient une erreur puisqu'elle renvoie systématiquement true...

Mais vos remarques m'ont aidé!

Voici le code modifié et opérationnel...

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
bool couleur_valide(char c)
{
    bool couleur_valide(0);
 
    if (c == '.' || c == 'R' || c == 'G' || c == 'B' || c =='C' || c == 'Y' || c == 'M')
    {
        //bool couleur_valide = true;
        couleur_valide = true;
    }
    else
    {
        //bool couleur_valide = false;
        couleur_valide = false;
    }
        cout<<c<<endl;
        cout<<couleur_valide<<endl;
 
        return couleur_valide;
 
 
}

[koala01]

Salut,

Je n'ai pas mis la variable retournée.

Ben oui, tout le problème est là...

Tu indiquais explicitement au compilateur que ta fonction doit renvoyer une valeur qui ne peut être que true (la couleur est valide) ou false, mais tu ne demandais nulle part à ce qu'une de ces valeurs ne soit renvoyée.

Et le compilateur te le faisait normalement savoir en émettant un avertissement du genre de

Code :

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

warning: no return statement in function returning non-void [-Wreturn-type]

Du moment que j'affiche la variable c et le booléen...

Ben, non... ta fonction est sensée tester la validité du caractère qui lui est donné... Elle n'a absolument pas besoin de l'afficher, en raison du principe de la responsabilité unique : tout type de donnée, toute donnée, toute fonction ne doit servir qu'à une seule chose, afin de pouvoir le faire correctement

Si tu veux absolument afficher le résultat, ca doit se faire "ailleurs" (sans doute lorsque tu as le résultat de la vérification ).

Et c'est d'autant plus vrai que l'on ignore complètement, au niveau de ta fonction couleur_valide, d'où vient le caractère qui doit être testé.

Pour l'instant, tu sembles récupérer le caractère à partir du clavier, et l'affichage ne va donc se faire qu'après qu'il y ait eu une intervention explicite de la part de l'utilisateur de ton programme, et donc, il pourrait n'avoir lieu qu'une seule et unique fois.

Seulement, le caractère testé pourrait tout aussi bien venir "d'ailleurs", comme par exemple:

• d'un fichier contenant 3 000 000 de caractères (chaque caractère devant être testé)
• d'un serveur envoyant les caractères un à un
• d'un port série sur lequel on récupère les données envoyées (toutes les millisecondes) par un appareil de mesure quelconque
• j'en passe, et sans doute de meilleures

On peut donc très facilement imaginer une situation dans laquelle cette fonction serait appelée "un grand nombre" de fois très rapidement ce qui provoquerait un grand nombre d'affichages se suivant très rapidement.

Et l'affichage pourrait alors très rapidement devenir une gène plus qu'autre chose, ne serait-ce que à cause du temps nécessaire pour qu'il s'exécute et, surtout, parce qu'il pourrait "très rapidement" devenir très compliqué de retrouver l'affichage d'un caractère particulier parmi les milliers voir les millions de caractères qui ont été testés

Pour les or à la place des ||, c'est une déformation iussue de 40 années d'assembleur...

Oui, effectivement, cela fonctionne... Mais pas exactement de la manière que l'on espère

Il faut en effet savoir qu'il y a une différence de taille entre le mot clé or et l'opérateur || dans le sens où, alors que le mot clé or représente une disjonction en algèbre de bool, l'opérateur || est ce que l'on appelle un "opérateur optimisé": si l'on a l'expression condition_1 || condition_2 la condition_2 ne sera testée que si sa valeur a encore une chance de changer la valeur finale de l'expression. Dans le cas présent, si condition_1 donne déjà un résultat égal à true condition_2 ne sera donc pas testée, car le résultat ne pourra plus changer quoi qu'il arrive.

Ce n'est pas le cas du mot clé or (ou de l'opérateur équivalent |), qui applique littéralement une disjonction booléenne et qui va donc tester l'expression dans son ensemble avant de fournir un résultat final.

Ça compile sans problème...et c'est bien là mon souci...

oui, mais l'avertissement t'indique clairement qu'il n'y a aucune instruction return pour une fonction qui est sensée renvoyer un booléen... Dés lors, la question est: d'où vient la valeur que tu récupères

En fait, on se trouve typiquement dans un cas de comportement indéfini (undefined behaviour): un comportement pour lequel il n'y a pas de "bonne réponse générale" et qui est laissé à l'appréciation des développeurs du compilateur.

Il semblerait que l'équipe qui a développé le compilateur que tu utilises ait choisi de considérer que la valeur dans ce cas là serait équivalente à true... L'équipe qui a développé un autre compilateur peut très bien avoir décidé que cette situation serait équivalente à false

Manifestement ma fonction contient une erreur puisqu'elle renvoie systématiquement true...

Et oui, en effet...

Et le compilateur l'a d'ailleurs remarqué, même si cette erreur ne justifiait pas d'arrêter la compilation.

Tu viens donc d'apprendre un point capital: une compilation réussie ne signifie absolument pas qu'il n'y a aucune erreur de logique. Cela signifie uniquement que le code est valide dans le sens où il respecte la syntaxe et la grammaire du langage.

Par chance, il existe une liste longue comme le bras de situations dans lesquelles le compilateur est capable de se rendre compte qu'un code valide risque malgré tout de poser problème sans forcément devoir arrêter la compilation (parce que le compilateur n'a aucun moyen de savoir si le "problème" rencontré vient d'une "distraction" ou d'une volonté claire et justifiée de la part du codeur. Par chance, quand le compilateur va systématiquement indiquer qu'il a rencontré un "éventuel problème". Et l'on est généralement "bien inspiré" d'en tenir compte afin -- le cas échéant -- de trouver le moyen de corriger ce problème potentiel

[debuteenc]

Merci beaucoup pour ces infos. Relativement à l'affichage il ne sert qu'au "debuggage". Une grosse erreur était de déclarer 2 fois la variable bool...
Avec ces corrections le programme fonctionne parfaitement. Grâce à vous, je serai, désormais plus attentif aux messages du compilateur!

Je tiens à saluer votre sérieux, votre disponibilité et votre diligence

Bonne semaine

[koala01]

Merci beaucoup pour ces infos. Relativement à l'affichage il ne sert qu'au "debuggage".

J'en ai bien conscience, mais tu peux te dire que ce n'est pas une bonne idée...

Si tu dois débugger un programme, tu as largement intérêt à utiliser les outils prévus pour (comme ... le débuggeur, par exemple) qui te permettra -- a priori -- bien mieux de savoir quelle valeur a été utilisée à quel moment et, surtout, la manière dont elle a été obtenue

N'oublie en outre jamais que, bien souvent, le moment où l'erreur devient "visible" parce qu'on utilise une valeur incorrecte est souvent très loin du moment où cette valeur a été définie et que c'est le moment de la définition de la valeur qui t'intéresse le plus: comment se fait il que la valeur que tu vas utiliser "plus tard" ne corresponde pas à la valeur à laquelle tu devrais pouvoir t'attendre

[kaitlyn]

Salut,

Il faut en effet savoir qu'il y a une différence de taille entre le mot clé or et l'opérateur || dans le sens où, alors que le mot clé or représente une disjonction en algèbre de bool, l'opérateur || est ce que l'on appelle un "opérateur optimisé": si l'on a l'expression condition_1 || condition_2 la condition_2 ne sera testée que si sa valeur a encore une chance de changer la valeur finale de l'expression. Dans le cas présent, si condition_1 donne déjà un résultat égal à true condition_2 ne sera donc pas testée, car le résultat ne pourra plus changer quoi qu'il arrive.

Ce n'est pas le cas du mot clé or (ou de l'opérateur équivalent |), qui applique littéralement une disjonction booléenne et qui va donc tester l'expression dans son ensemble avant de fournir un résultat final.

Juste pour dire que tout ce que tu as écrit là est erroné. Comme foetus ne l'a pas dit alors je te le dis.
Mais plaisanterie à part, or correspond bien à ||, par contre ce qui correspond à | c'est bitor.

[foetus]

Mais plaisanterie à part, or correspond bien à ||, par contre ce qui correspond à | c'est bitor.

Il faut donner l'entête : iso646.h en C/ ciso646 en C++ (<- lien cplusplus.com en anglais)

Mais @koala01 a raison de rappeler qu'il existe des opérateurs logiques (!, ||, &&) et des opérateurs binaires (~, |, &, ^ (XOR, le sheriff de l'espace), <<, >>).
Cela évite quelques surprises


Édit : suite à la remarque ci-dessous de @kaitlyn, effectivement en C++ et c'est noté dans mon lien, les mots sont réservés et donc l'inclusion ne fait rien.