Discussion :

[Kindersurpriz]

Bonjour à tous.

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

Code :

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

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!

[Laurent Gomila]

En meilleur C++ :

Code :

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

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.

[Spout]

Salut,

Code :

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

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.

[Kindersurpriz]

ok merci !!

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

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

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

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

[Noxen]

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

Exemple:

Code :

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

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

[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 :/

[Médinoc]

Dans ce code, j'aurais utilisé "|" (Opérateur OU bit-à-bit) plutôt que "+" (Addition)...

[JolyLoic]

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

[Spout]

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

[HanLee]

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 :

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

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

Code :

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

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 :

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

1
2
3
int offset = bHasNormals
           ? 6
           : 3;

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

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

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

[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(){}.

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

[Spout]

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 .

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

[JolyLoic]

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 :

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

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 :

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

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