soit interprétée "comme il se doit" par le compilateur (gcc), à savoir :
(toto.t)[2]=33;
alors que l'opérateur d'indexation [] a une priorité supérieure à
l'opérateur de sélection directe . en sorte que l'affectation initiale
devrait être comprise comme l'instruction (erronée) suivante :
toto.(t[2])=33;
?
Merci
P.S. Où la norme discute-t-elle de la précédence des opérateurs ? Il y a
un tableau des priorités quelque part ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Damien Goutte-Gattat
Bonjour,
candide wrote:
P.S. Où la norme discute-t-elle de la précédence des opérateurs ? Il y a un tableau des priorités quelque part ?
À priori, dans la section 6.5, "Expressions", dans une note de bas de page :
" The syntax specifies the precedence of operators in the evaluation of an expression, which is the same as the order of the major subclauses of this subclause, highest precedence first. Within each major subclause, the operators have the same precedence. "
Donc d'une certaine manière, c'est la table des matières qui fait office de "tableau des priorités", les opérateurs décrits en 6.5.n ayant la même priorité, supérieure à celle des opérateurs décrits en 6.5.n+1.
Du coup, pour la question principale :
Comment se fait-il que l'affectation
toto.t[2]3;
soit interprétée "comme il se doit" par le compilateur (gcc), à savoir :
(toto.t)[2]3;
alors que l'opérateur d'indexation [] a une priorité supérieure à l'opérateur de sélection directe . en sorte que l'affectation initiale devrait être comprise comme l'instruction (erronée) suivante :
toto.(t[2])3;
Les opérateurs d'indexation [] et de sélection . sont tous les deux décrits dans la même sous-section (6.5.2, "Postfix operators"), en application de la note ci-dessus ils doivent donc avoir la même priorité.
En conséquence, c'est l'associativité à gauche de ces opérateurs qui intervient ici et qui conduit à interpréter "toto.t" comme premier opérande de [], et non "t[2]" comme second opérande de .
Sous réserve d'erreur grossière de ma part bien sûr.
Damien
Bonjour,
candide wrote:
P.S. Où la norme discute-t-elle de la précédence des opérateurs ? Il y a
un tableau des priorités quelque part ?
À priori, dans la section 6.5, "Expressions", dans une note de bas de
page :
"
The syntax specifies the precedence of operators in the evaluation of an
expression, which is the same as the order of the major subclauses of
this subclause, highest precedence first. Within each major subclause,
the operators have the same precedence.
"
Donc d'une certaine manière, c'est la table des matières qui fait office
de "tableau des priorités", les opérateurs décrits en 6.5.n ayant la même
priorité, supérieure à celle des opérateurs décrits en 6.5.n+1.
Du coup, pour la question principale :
Comment se fait-il que l'affectation
toto.t[2]3;
soit interprétée "comme il se doit" par le compilateur (gcc), à savoir :
(toto.t)[2]3;
alors que l'opérateur d'indexation [] a une priorité supérieure à
l'opérateur de sélection directe . en sorte que l'affectation initiale
devrait être comprise comme l'instruction (erronée) suivante :
toto.(t[2])3;
Les opérateurs d'indexation [] et de sélection . sont tous les deux
décrits dans la même sous-section (6.5.2, "Postfix operators"), en
application de la note ci-dessus ils doivent donc avoir la même priorité.
En conséquence, c'est l'associativité à gauche de ces opérateurs qui
intervient ici et qui conduit à interpréter "toto.t" comme premier
opérande de [], et non "t[2]" comme second opérande de .
Sous réserve d'erreur grossière de ma part bien sûr.
P.S. Où la norme discute-t-elle de la précédence des opérateurs ? Il y a un tableau des priorités quelque part ?
À priori, dans la section 6.5, "Expressions", dans une note de bas de page :
" The syntax specifies the precedence of operators in the evaluation of an expression, which is the same as the order of the major subclauses of this subclause, highest precedence first. Within each major subclause, the operators have the same precedence. "
Donc d'une certaine manière, c'est la table des matières qui fait office de "tableau des priorités", les opérateurs décrits en 6.5.n ayant la même priorité, supérieure à celle des opérateurs décrits en 6.5.n+1.
Du coup, pour la question principale :
Comment se fait-il que l'affectation
toto.t[2]3;
soit interprétée "comme il se doit" par le compilateur (gcc), à savoir :
(toto.t)[2]3;
alors que l'opérateur d'indexation [] a une priorité supérieure à l'opérateur de sélection directe . en sorte que l'affectation initiale devrait être comprise comme l'instruction (erronée) suivante :
toto.(t[2])3;
Les opérateurs d'indexation [] et de sélection . sont tous les deux décrits dans la même sous-section (6.5.2, "Postfix operators"), en application de la note ci-dessus ils doivent donc avoir la même priorité.
En conséquence, c'est l'associativité à gauche de ces opérateurs qui intervient ici et qui conduit à interpréter "toto.t" comme premier opérande de [], et non "t[2]" comme second opérande de .
Sous réserve d'erreur grossière de ma part bien sûr.
Damien
candide
À priori, dans la section 6.5, "Expressions", dans une note de bas de page :
Ah ok j'avais vraiment pas pensé à regarder une info aussi importante dans une footnote !!!! (1) Et la toc qui fait office de tableau, pas mal dans le genre !
Les opérateurs d'indexation [] et de sélection . sont tous les deux décrits dans la même sous-section (6.5.2, "Postfix operators"), en application de la note ci-dessus ils doivent donc avoir la même priorité.
Ah oui, bien sûr. Je m'étais fié au tableau dans le Harbison & Steele et [] et . y sont sur des lignes différentes et j'avais pas fait gaffe qu'ils ont le même numéro de précédence. Faut dire que Harbison&Steele et ergonomie ça fait deux. Je suis pas toujours très attentif non plus !
OK, je te remercie de ces précieuses indications.
_______ (1) On m'a prendre conscience récemment que les info sur la promotion intégrale sont en fait largement limitées par une footnote (§6.2 de C90)? Bah, ne nous plaignons pas, on n'a pas des footnotes dans les footnotes !
À priori, dans la section 6.5, "Expressions", dans une note de bas de
page :
Ah ok j'avais vraiment pas pensé à regarder une info aussi importante
dans une footnote !!!! (1)
Et la toc qui fait office de tableau, pas mal dans le genre !
Les opérateurs d'indexation [] et de sélection . sont tous les deux
décrits dans la même sous-section (6.5.2, "Postfix operators"), en
application de la note ci-dessus ils doivent donc avoir la même priorité.
Ah oui, bien sûr. Je m'étais fié au tableau dans le Harbison & Steele et
[] et . y sont sur des lignes différentes et j'avais pas fait gaffe
qu'ils ont le même numéro de précédence. Faut dire que Harbison&Steele
et ergonomie ça fait deux. Je suis pas toujours très attentif non plus !
OK, je te remercie de ces précieuses indications.
_______
(1) On m'a prendre conscience récemment que les info sur la promotion
intégrale sont en fait largement limitées par une footnote (§6.2 de
C90)? Bah, ne nous plaignons pas, on n'a pas des footnotes dans les
footnotes !
À priori, dans la section 6.5, "Expressions", dans une note de bas de page :
Ah ok j'avais vraiment pas pensé à regarder une info aussi importante dans une footnote !!!! (1) Et la toc qui fait office de tableau, pas mal dans le genre !
Les opérateurs d'indexation [] et de sélection . sont tous les deux décrits dans la même sous-section (6.5.2, "Postfix operators"), en application de la note ci-dessus ils doivent donc avoir la même priorité.
Ah oui, bien sûr. Je m'étais fié au tableau dans le Harbison & Steele et [] et . y sont sur des lignes différentes et j'avais pas fait gaffe qu'ils ont le même numéro de précédence. Faut dire que Harbison&Steele et ergonomie ça fait deux. Je suis pas toujours très attentif non plus !
OK, je te remercie de ces précieuses indications.
_______ (1) On m'a prendre conscience récemment que les info sur la promotion intégrale sont en fait largement limitées par une footnote (§6.2 de C90)? Bah, ne nous plaignons pas, on n'a pas des footnotes dans les footnotes !
Vincent Lefevre
Dans l'article <48125702$0$5047$, candide écrit:
À priori, dans la section 6.5, "Expressions", dans une note de bas de page :
Ah ok j'avais vraiment pas pensé à regarder une info aussi importante dans une footnote !!!! (1)
Les footnotes ne sont pas normatives. Cette information doit donc se trouver ailleurs: c'est la syntaxe qui indique la précédence.
Et la toc qui fait office de tableau, pas mal dans le genre !
Pourquoi pas? Ce n'est de toute façon pas normatif (encore une fois).
