Discussion :

[Chezkele]

Bonjour,

est-ce que vous auriez un exemple en C où la question de la priorité entre les opérateur "->" et "." se pose?

Je connais les priorités respectives de ces opérateurs, mais je cherche s'il existe des cas où la question se pose en C.

en vous remerciant

[Bousk]

Je vois pas comment la question pourrait se poser, ce sont 2 opérateurs de suffixe, y'a (quasi?) aucune chance qu'ils clashent.
Les questions pourraient se poser quand tu as des syntaxes comme *toto->tati, (*toto)->tati ou (*toto).tati

[mintho carmo]

Opinion personnelle : on s'en fout de la priorité des opérateurs.

On voit souvent des questions sur le sujet lors des tests techniques, parce que c'est des questions pas forcément simple. Mais est-ce qu'on veut dans nos codes des syntaxes dont la moitié des devs sont susceptibles de se tromper ? Même un dev qui connait les règles peut facilement se tromper.

Donc ce sont des règles a exclure du code, il faut explicitement indiquer la priorité avec des parenthèses. C'est complètement idiot de faire l'économie de 2 caractères dans un code (et qui n'a aucun impact sur les binaires après compilation). C'est plus explicite et plus safe.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
// écrire
(2 * 3) + 5
 
(*toto)->tati
 
*(++p)
 
// plutôt que
2 * 3 + 5
 
*toto->tati
 
*++p

etc

[dalfab]

Opinion personnelle : on s'en fout de la priorité des opérateurs.

On voit souvent des questions sur le sujet lors des tests techniques, parce que c'est des questions pas forcément simple. Mais est-ce qu'on veut dans nos codes des syntaxes dont la moitié des devs sont susceptibles de se tromper ? Même un dev qui connait les règles peut facilement se tromper.

Donc ce sont des règles a exclure du code, il faut explicitement indiquer la priorité avec des parenthèses. C'est complètement idiot de faire l'économie de 2 caractères dans un code (et qui n'a aucun impact sur les binaires après compilation). C'est plus explicite et plus safe.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
// écrire
(2 * 3) + 5
 
(*toto)->tati
 
*(++p)
 
// plutôt que
2 * 3 + 5
 
*toto->tati
 
*++p

etc

Mettre des parenthèses alors qu'elles ne sont pas nécessaires, n'est pas toujours plus clair. Quelques exemples:
Au fait, l'équivalent de *toto->tati c'est *(toto->tati), ça n'est pas (*toto)->tati comme tu l'indiques. Ca n'est pas évident pour toi donc en effet tu devrais utiliser des parenthèses

Mais si j'écris *ptr++, c'est en effet difficile à lire, mais si je l'écris identiquement avec des parenthèses *(ptr++), je penses que cela est plus perturbateur pour beaucoup de monde (on peut avoir l'impression que le ++ est fait avant *).
Ecrire a.b.c() me paraît plus lisible que son équivalent avec des parenthèses ((a.b).c)().

Pour revenir à . et ->, ils ne sont jamais en conflit, tous les deux sont interprétés immédiatement. Par exemple a.b.c->d.e n'est pas ambiguë, c'est forcément a.(b.(c->(d.e))).
Par contre pour .* et ->*, là on a une expression potentiellement complexe a->*b.c est-il (a->*b).c ou a->*(b.c)? C'est le second qui s'applique.

edit : du coup je me suis gourré, c'est (((a.b).c)->d).e pour a.b.c->d.e.

[mintho carmo]

Ca n'est pas évident pour toi donc en effet tu devrais utiliser des parenthèses

Erreur involontaire de ma part, mais je reconnais sans problème que :
1. j'ai pas trop fait attention (ce qui arrive régulièrement dans les vrais projets)
2. je suis très content d'avoir oublié, avec le temps, ce genre de choses inutiles

sauf quand on lit le code de quelqu'un d'autre … comme par exemple trouver l'erreur dans le code que tu donnes (en supposant que tu donnais les équivalences)

La confusion ne peut arriver que dans un code sans parenthèse. Dans un code sans parenthèse, on ne peut pas savoir si c'est un choix volontaire de la part du dev ou s'il a fait une erreur sur les règles de priorité des opérateurs. Avec des parenthèses, il peut encore y avoir des erreurs, mais l'intention du dev est explicite.

Je ne laisse passer aucun de ces codes en review sans parenthèse. Je demande au dev qu'il exprime explicitement avec des parenthèses ce qu'il veut faire, je n'essaie pas de deviner ses intentions (ou de savoir si un dev plus tard fera une erreur).

edit : du coup je me suis gourré

J'oserais dire que cette correction prouve que j'ai complètement raison d'interdire les codes sans parenthèse. Et je me permet : "Ca n'est pas évident pour toi donc en effet tu devrais utiliser des parenthèses"

[Bktero]

Je ne suis tellement pas d'accord

Il y a des cas où mettre des parenthèses est effectivement un plus pour éviter les erreurs. Même si tu connais par cœur toutes les priorités des opérateurs et que tu peux écrire ton code avec certitude sans parenthèse, tu ne peux pas demander / garantir que les autres personnes de ton équipe seront dans le même cas. Ainsi, je vois clairement un intérêt à *ptr++ vs (*ptr)++ vs *(ptr++).

Toutefois, il y a des cas tellement évidents et connus de toute le monde (et si ce n'est pas le cas, il faudrait peut-être réviser) et mettre des parenthèses est inutile, voire contre-productif. Quand on lit a + b * c / e - f, on sait qu'on applique les priorités des opérateurs. Quand on met des parenthèses et qu'on obtient quelque chose comme (je crois que c'est pareil) ((a + ((b * c) / e)) - (f)), le lecteur ou la lectrice se dira sans doute "ah ! des parenthèses, donc on fait qq chose de spécial...... hein quoi ?....... ah non en fait.....je vais quand même re-vérifier".

[WhiteCrow]

Opinion personnelle : on s'en fout de la priorité des opérateurs.

sauf quand on lit le code de quelqu'un d'autre … comme par exemple trouver l'erreur dans le code que tu donnes (en supposant que tu donnais les équivalences) :

[...\

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
// écrire
(2 * 3) + 5
 
(*toto)->tati
 
*(++p)
 
// plutôt que
2 * 3 + 5
 
*toto->tati
 
*++p

[...]

*toto->tati se parenthèse en *(toto->tati) car les opérateurs d'accès à un membre (. ou ->) ont une précédence supérieure à l'opérateur de déréférencement (*).
. et -> ont la même précédence, il suffit de les associer de gauche à droite comme l'indique la doc.

Edit: grilled !