opérateur if ternaire

Version imprimable

06/08/2008, 13h57
Kindersurpriz

opérateur if ternaire
Bonjour à tous.

J'aurais besoin d'un petit coup de main pour comprendre ce que fait ce test :
Code:

1 2 3 int z,x,y; z = (x&1?0:1) + (y&1?0:2);
Serait-il possible d'avoir une petite traduction en langage courant, afin que je puisse le traduire en ... Pascal ... et oui, personne n'est parfait ^^

merci d'avance!
06/08/2008, 14h14
Laurent Gomila
En meilleur C++ :
Code:

1 2 3 4 5 int z = 0; if (!(x & 1)) // ou encore (x % 2) z += 1; if (!(y & 1)) // ou encore (y % 2) z += 2;
En langage humain :
z est composé de deux bits : le premier vaut 1 si x est pair, le second vaut 1 si y est pair.

Salut,

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
int z, x, y; // Attention, tes variables ne sont pas initialisées
 
if(x & 1) // masque sur le bit de poids faible de l'octet de poids faible de x
    // Le bit est à 1
else
    // Le bit est à 0
    z += 1;
 
if(y & 1) // masque sur le bit de poids faible de l'octet de poids faible de y
    // Le bit est à 1
else
    // Le bit est à 0
    z += 2;

test ? action/valeur si true : action/valeur si false est une notation abrégée d'un if.
Pas forcément très lisible.

06/08/2008, 14h20
Kindersurpriz

ok merci !! :yaisse2:
06/08/2008, 14h44
Kindersurpriz
ouch !
en fait, un peu plus loin, toujours dans le même code écrit par une personne qui apparemment avait pas envi d'être relue, on peut lire
Code:

1 2 3 4 5 6 unsigned char *output,input; char *ptr = (char*)input; int z; output[i+z] = (x&1)? ptr[x>>1]:ptr[(w>>1)+(x>>1)];
ce coup ci, c'est plus sur le " >> " que je bloque
06/08/2008, 15h19
Laurent Gomila

>> est un décalage de bits vers la droite.
>> 1 est donc un décalage de 1 bit, ou dit autrement, une division par deux.

Opérateurs de décalage à gauche (<<) et de décalage à droite (>>).

Exemple:
Code:

1 2 3 4 5 6 byte b = 9; // en binaire : 00001001 b = b << 1; // == décaler les bits de 1 rang vers la gauche => 00010010 // b == 18 b = b >> 3; // == décaler les bits de 3 rangs vers la droite => 00000010 // b == 2
Note : chaque rang de décalage vers la gauche équivaut à doubler le nombre, et chaque rang de décalage vers la droite équivaut à diviser par 2 (arondi à l'inférieur), puisqu'on est en base 2 ( base 10 se serait des multiplications/divisions par 10).

Ici:

Si x est impair:
mettre dans output[i+z] le caractère de ptr[] (ou de input) situé à x/2;
sinon:
mettre dans output[i+z] le caractète de ptr situé à (w/2)+(x/2)

'tin, difficile de faire moins clair, qui c'est qui s'est amusé à faire un truc pareil ? Tu fais quoi comme boulot, de la maintenance applicative ? Dire que depuis un moment je n'arrête pas de lire et entendre dire partout qu'il est important de faire un code facile à lire et à reprendre, quitte à ce que ce soit aux dépend de ce genre de soit-disant optimisations...

Bon courage, le type qui est passé avant toi a l'air d'être un grand communicant... :?

06/08/2008, 15h32
Kindersurpriz

nan, je tente de faire marcher une dll écrite en C++ sous delphi. Seulement là ou je bosse (en stage) ils ont des pc tellement bien que j'arrive pas à ouvrir une dll, du coup je la traduit en pascal et j'en fait une fiche de mon projet :/
07/08/2008, 09h01
Médinoc

Dans ce code, j'aurais utilisé "|" (Opérateur OU bit-à-bit) plutôt que "+" (Addition)...
07/08/2008, 11h40
JolyLoic

Citation:

Envoyé par spoutspout

test ? action/valeur si true : action/valeur si false est une notation abrégée d'un if.
Pas forcément très lisible.

Il y a plein de cas où cette notation est plus lisible qu'un if. Pour moi, l'obfuscation dans le code initial vient plutôt que l'utilisation des & ou des >>1
07/08/2008, 12h04
Spout

Citation:

Envoyé par JolyLoic

Il y a plein de cas où cette notation est plus lisible qu'un if.

Tout dépend de ce que tu entends par "lisible".
Pour moi, un code utilisant ce genre de notation ne fait qu'en obscurcir la compréhension. Car tout le monde ne l'utilise pas (la preuve ici) et elle fait abstraction de plusieurs mots clés du C++ (if, else) qui sont plus parlants qu'une série de '?' et de ':' pour quelqu'un qui se plonge dans ton code.

Maintenant, pour un gain de temps de codage (~flemme ?), si on est et sera le seul à bosser sur un code, je ne suis pas contre l'utiliser car on sait ce que c'est. Sauf que l'on est jamais rarement tout seul sur un projet (pour le développement autant que pour le MCO).
07/08/2008, 13h26
HanLee
Citation:

Envoyé par spoutspout

Tout dépend de ce que tu entends par "lisible".
Pour moi, un code utilisant ce genre de notation ne fait qu'en obscurcir la compréhension. Car tout le monde ne l'utilise pas (la preuve ici) et elle fait abstraction de plusieurs mots clés du C++ (if, else) qui sont plus parlants qu'une série de '?' et de ':' pour quelqu'un qui se plonge dans ton code.

Maintenant, pour un gain de temps de codage (~flemme ?), si on est et sera le seul à bosser sur un code, je ne suis pas contre l'utiliser car on sait ce que c'est. Sauf que l'on est jamais rarement tout seul sur un projet (pour le développement autant que pour le MCO).

Ben un des defauts du if-else du C/C++, c'est que ce n'est pas une fonction, alors que dans les langages fonctionnels si.

Tu ne peux pas dire :

Code:

int offset = if (bHasNormals) { 6; } else { 3; }
Code:

1 2 3 4 5 int offset; if (bHasNormals) offset = 6; else offset = 3;
Super, vive les effets de bords, et c'est maladroit.
Dans certains cas, tu peux te payer une construction par défaut chère.

Là moi j'écris et c'est aussi lisible.
Code:

1 2 3 int offset = bHasNormals ? 6 : 3;
07/08/2008, 14h27
Klaim
Il y a un cas où il m'arrive d'être contraint d'utiliser cette notation : dans les listes d'initialization où il y a des constantes à initializer.
Code:

1 2 3 4 5 6 7 8 9 class Thing { const int m_machin; public: Thing( const Bidule& bidule ) : m_machin( bidule.hasMachin() ? bidule.getMachin() : -1 ) { }
(exemple a l'arrache evidemment)

Ca reste plutot rare mais quand en concevant des systemes avec un maximum de consts, je tombe parfois sur ce genre de cas.

edit> En fait c'est pareil pour tout ce qui est initialization conditionnelle de constantes...
07/08/2008, 14h42
3DArchi

La plus part des règles de codage que j'ai vues dans les boîtes interdisent/découragent l'utilisation du ?: et demandent explicitement le if(){}else(){}.
07/08/2008, 14h56
JolyLoic

Et je crois que je refuserait de travailler dans une telle boîte. Il y a de nombreux cas où ?: améliore la lisibilité. Ca ne fait pas la même chose qu'un if. Il y a des cas où un if est plus clair, d'autres où un ?: est plus clair, d'autres cas plus nuancés.
07/08/2008, 15h39
Spout

Citation:

Envoyé par JolyLoic

Il y a des cas où un if est plus clair, d'autres où un ?: est plus clair, d'autres cas plus nuancés.

Ok pour ça :mrgreen:.
07/08/2008, 15h45
3DArchi

Les règles de codage sont issues à la fois de l'habitude de faire des gens qui les rédigent :( et puis du fruit de l'expérience :).
Globalement, je pense que if/else à la place du ?: a surtout comme objectif de maintenir la lisibilité et n'est pas si contraignante que ça (à contrario, une fois, dans un projet C++, il était interdit de faire du template et des exceptions: là, ça m'a paru plus aberrant).
Maintenant, à titre perso, quand je n'ai pas de telles règles à respecter, j'utilise l'opérateur ternaire. Comme l'a dit Klaim je crois, ça reste souvent dans le cadre d'initialisation.
07/08/2008, 20h04
JolyLoic
Citation:

Envoyé par 3DArchi

Globalement, je pense que if/else à la place du ?: a surtout comme objectif de maintenir la lisibilité

C'est justement ce point que je conteste. Déjà, je n'ai pas vu d'argument qui m'expliquerait en quoi ?: serait intrinsèquement moins lisible que if (à part de la part de gens qui font #define BEGIN {).

Ensuite, je voulais développer un cas classique où je trouve ?: plus lisible. Exemple ici d'un code que j'ai tapé aujourd'hui (programme non livré au client, donc détection d'erreur minimaliste):
Code:

1 2 3 4 5 6 7 8 9 10 int seed; if (argc == 2) { seed = lexical_cast<double>(argv[1]); } else { seed = time(NULL); }
Code:

1 2 3 int seed = (argc == 2) ? lexical_cast<double>(argv[1]) : time(NULL);
Quand je lis le code 1, je me dis : Bon, maintenant, on va parcourir les arguments passés en ligne de commande.
Quand je lis le code 2, je me dis : Bon, maintenant, on va initialiser la graine du générateur aléatoire.

Le if met l'accent sur l'élément de test, le ?: met l'accent sur la finalité de celui-ci.

Les deux peuvent être valides, mais je donne un sens différent à mon code selon celui que j'utilise. Par exemple, si mon programme acceptait plusieurs arguments, dans le code 1, je m'attendrais à avoir tout de suite après le traitement de l'argument suivant. Pas forcément dans le code 2.

Autre aspect, dans le code 2, je n'ai pas de variable non initialisée, j'en ai une dans le code 1. A lui seul, cet argument me fait préférer ?: dans un certain nombre de cas (tout comme un ?: à l'intérieur d'un return peut faire un code plus proche d'un code SESE, même si je ne prône pas particulièrement ce style).