explication d'une expression

Salut a tous,

Je ne comprend pas cette expression, est ce que quelqu'un peut m'expliquer svp?

Code:

---

size++[result] = c

---

L'explication t'a déjà été donnée ici http://www.developpez.net/forums/sho...96&postcount=4 il me semble...

Salut, si je ne me trompe pas, cette expression est équivalente à:

Code:

---

1 2	*(size + result)= c; /* stock c à l'adresse pointée par size + result (voir arithmétique des pointeurs)*/ size = size + 1; /* incrémente size */

---

Salutations

Thierry

Ou plus simplement:

Code:

---

1 2	result[size] = c; size++;

---

Citation:

---

Envoyé par Médinoc

Ou plus simplement:
Code :

result[size] = c; size++;

---

Autant pour moi, c'est plus lisble!!!

Thierry

merci pour votre aide

Citation:

---

Envoyé par Pitou5464

Code:

---

size++[result] = c

---

---

Celui qui écrit du code comme ça mérite le miel et les fourmis rouges.

http://www.apinchof.com/honeybook.jpg
http://msucares.com/insects/vegetabl...s/fireants.jpg

Ouais, d'accord à 100%, même si ce code, c'est déjà un peu ce que tu dis, donc pas la peine de s'acharner plus que ça (je plaisante, bien sûr) !

Je ne suis même pas sûr que ce soit du C-ANSI, car il est normalement interdit d'effectuer plus d'un effet de bord entre deux "points de séquence" ("sequence point", je crois, dans le man de gcc), même si il semblerait qu'il existe des desaccords sur le sens de cette expression.

Quelqu'un pourrait-il m'en dire plus sur ces "sequence points", car le notion que j'en ai n'est pas très précise ? Merci d'avance.

Citation:

---

Envoyé par InOCamlWeTrust

Quelqu'un pourrait-il m'en dire plus sur ces "sequence points", car le notion que j'en ai n'est pas très précise ? Merci d'avance.

---

C'est défini dans la norme

http://www.open-std.org/jtc1/sc22/wg...docs/n1124.pdf

http://www.mygroceryshop.com.au/imag...spro_extra.jpg

Merci beaucoup pour le lien.

Il semblerait que la dernière norme (si c'est bien celle-ci) soit plus permissive que la norme ANSI. La norme ANSI spécifiait qu'il ne pouvait y avoir qu'un seul effet de bord entre deux points de séquence, alors que cette norme-ci dit seulement que les effets de bords contenus entre points de séquence ne peuvent pas se chevaucher : en clair, arrivé à un point de séquence, tous les effets de bords précédents doivent avoir été évalués, et ceux à venir ne doivent pas avoir pris effet.

La définition des points de séquence est d'ailleurs assez claire (annexe C).

Citation:

---

Envoyé par InOCamlWeTrust

Il semblerait que la dernière norme (si c'est bien celle-ci) soit plus permissive que la norme ANSI. La norme ANSI spécifiait qu'il ne pouvait y avoir qu'un seul effet de bord entre deux points de séquence, alors que cette norme-ci dit seulement que les effets de bords contenus entre points de séquence ne peuvent pas se chevaucher : en clair, arrivé à un point de séquence, tous les effets de bords précédents doivent avoir été évalués, et ceux à venir ne doivent pas avoir pris effet.

---

Il n'y a pas de changement sur le fond. Ce genre de choses a toujours été autorisé.

Citation:

---

La définition des points de séquence est d'ailleurs assez claire (annexe C).

---

C'esy bizarre, on se demande alors pourquoi il y a tant d'efforts pour les reformuler. Quelques exemples pour le comité C après 2000 (et le comité C++ est actif lui aussi et va vraissemblablement les supprimer de la prochaine norme pour les remplacer par des contraintes entre expressions et il n'est pas invraissemblable que le comité C reprenne la formulation du comité C++).

http://www.open-std.org/jtc1/sc22/wg...docs/n1188.pdf
http://www.open-std.org/jtc1/sc22/wg...docs/n1013.htm
http://www.open-std.org/jtc1/sc22/wg...docs/n1008.htm
http://www.open-std.org/jtc1/sc22/wg...docs/n1001.htm
http://www.open-std.org/jtc1/sc22/wg.../docs/n993.htm
http://www.open-std.org/jtc1/sc22/wg.../docs/n927.htm
http://www.open-std.org/jtc1/sc22/wg.../docs/n926.htm
http://www.open-std.org/jtc1/sc22/wg.../docs/n925.htm

Citation:

---

Envoyé par Jean-Marc.Bourguet

Il n'y a pas de changement sur le fond. Ce genre de choses a toujours été autorisé.

---

C'est bien ce que j'ai compris : c'est pourquoi j'employais l'adverbe "seulement" dans le message.

Citation:

---

Envoyé par Jean-Marc.Bourguet

C'esy bizarre, on se demande alors pourquoi il y a tant d'efforts pour les reformuler.

---

Ben, je sais bien, et je suis même surpris moi-même... ou alors il doit y avoir une subtilité qui m'échappe ! Le seul cas que je trouve étrange, mais inambigu, est celui-ci :

Citation:

---

Envoyé par Standard du C, Annexe C

The end of a full expression: an initializer (6.7.8); the expression in an expression statement (6.8.3);

---

Si je me reporte au paragraphe 6.8.3, je vois ceci :

Citation:

---

Envoyé par Standard du C, paragraphe 6.8.3

6.8.3 Expression and null statements

Syntax
1 expression-statement: expression_opt ;

Semantics
2 The expression in an expression statement is evaluated as a void expression for its side effects.132)
3 Anull statement (consisting of just a semicolon) performs no operations.
[...]

---

J'en déduis que ce genre d'expression contient un et un seul point de séquence, avec deux effets de bord, qui ne serait donc pas autorisé en C-ANSI (mais dont les codes de Knuth en sont bourrés !) :

Code:

---

1 2 3

/* x et y sont des int */ x = (y = 7) + 4;

---

Si quelqu'un voit où je me trompe, merci de me le faire remarquer, car je suis vraissemblablement dans l'erreur.

Citation:

---

Envoyé par InOCamlWeTrust

C'est bien ce que j'ai compris : c'est pourquoi
j'employais l'adverbe "seulement" dans le message.

---

Tu avais écrit:

Citation:

---

Il semblerait que la dernière norme (si c'est bien celle-ci) soit
plus permissive que la norme ANSI.

---

J'infirmais ton affirmation. Il n'y a pas eu d'évolution importante entre
C90 et C99 sur ce point.

Citation:

---

Ben, je sais bien, et je suis même surpris moi-même... ou alors il
doit y avoir une subtilité qui m'échappe ! Le seul cas que je trouve
étrange, mais inambigu, est celui-ci :

---

C'est normal, les subtilités échappent à beaucoup de monde. Je ne prétends
d'ailleurs pas qu'elles ne m'échappent pas: chaque fois que j'ai cru avoir
compris la formulation, je me suis retrouvé le bec dans l'eau tôt ou tard.
Quand je veux jouer au jeu formel de déterminer d'après la norme si quelque
chose est valable ou non, j'utilise d'abord un modèle personnel proche de
certains que j'ai cités pour savoir si c'est indéfini, défini par
l'implémentation ou bien défini. Ensuite je cherche des citations appuyant
ma position.

Parmi les choses dont je suis certains mais qui ne sont pas claires du tout
aux premières lectures, il y a le fait que la présence d'un point de
séquencement est une relation entre deux expressions qui contraint les
effets visibles de leurs évaluations respectives. Ça ne contraint en rien
les évaluations des autres expressions en présence. Dans

Code:

---

f(e1, e2 &&e3);

---

la présence du point de séquencement entre e2 et e3 n'a aucune influence
sur l'évaluation de e1.

Citation:

---

J'en déduis que ce genre d'expression contient un et un seul point
de séquence,

---

Pourquoi? Il y a un point de séquencement à la fin de l'expression, ça
n'empèche pas qu'il puisse en avoir ailleurs.

Citation:

---

avec deux effets de bord, qui ne serait donc pas autorisé en C-ANSI
(mais dont les codes de Knuth en sont bourrés !) :

---

Pourquoi? Ce qui est interdit c'est de modifier plusieurs fois le même
objet ou de modifier et de lire le même objet quand la lecture ne sert pas
à déterminer la valeur écrite.

Citation:

---

Code:

---

1 2 3

/* x et y sont des int */ x = (y = 7) + 4;

---

---

Il y a effectivement un seul point de séquencement et deux écritures dans
des objets différents.

Si tu écris:

Code:

---

*x = (*y = 7) + 4;

---

on a un comportement indéfini si x et y sont des pointeurs vers le même
objet.

Si tu écris:

Code:

---

x = (*y = 7) + z;

---

on a un comportement indéfini si y pointe vers x ou si y pointe vers z.

Un prof à l'ENSEEIHT (qui est loin d'être un ignare) m'a dit l'année dernière qu'il était impossible de faire deux effets de bord dans la même expression : je suppose qu'il devait sous-entendre "deux effets de bord entre deux points de séquencement". Est-ce exact ou non ? car faute de n'avoir accès au texte de la norme ANSI je n'ai d'autre choix que le croire !

Pour résumer ; mon petit exemple...

Code:

---

1 2	x = (y = 7) + 4;

---

... est-il ANSI ?

Les deux comportements que tu donnes, sont-ils les seuls interdits (dans ce cadre-ci) ? Je pose la question car je ne les ai pas rencontrés à le lecture du document.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Ce qui est interdit c'est de modifier plusieurs fois le même objet ou de modifier et de lire le même objet quand la lecture ne sert pas à déterminer la valeur écrite.

---

Par contre, pour ça...

Citation:

---

Parmi les choses dont je suis certains mais qui ne sont pas claires du tout aux premières lectures, il y a le fait que la présence d'un point de
séquencement est une relation entre deux expressions qui contraint les effets visibles de leurs évaluations respectives. Ça ne contraint en rien les évaluations des autres expressions en présence.

---

... j'avais compris à la première lecture, je pense que le document est assez clair sur ce point :

Citation:

---

Envoyé par Standard du C, 5.1.2.3

At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place. (A summary of the sequence points is given in annex C.)

---

Citation:

---

Envoyé par InOCamlWeTrust

Un prof à l'ENSEEIHT (qui est loin d'être un ignare) m'a dit l'année dernière qu'il était impossible de faire deux effets de bord dans la même expression : je suppose qu'il devait sous-entendre "deux effets de bord entre deux points de séquencement". Est-ce exact ou non ? car faute de n'avoir accès au texte de la norme ANSI je n'ai d'autre choix que le croire !

Pour résumer ; mon petit exemple...

Code:

---

1 2	x = (y = 7) + 4;

---

... est-il ANSI ?

---

Oui. Si ce n'était pas permis, l'utilisation des opérateurs ++ et -- serait fortement restreinte.

Citation:

---

Les deux comportements que tu donnes, sont-ils les seuls interdits (dans ce cadre-ci) ? Je pose la question car je ne les ai pas rencontrés à le lecture du document.

---

Je ne vois pas d'autres cas où l'exécution de ces expressions causerait un comportement indéfini.

Citation:

---

Par contre, pour ça...
... j'avais compris à la première lecture, je pense que le document est assez clair sur ce point :

---

La compréhension que la relation "précède" n'était pas un ordre total sur les points de séquencement n'a pas été aussi simple pour moi.

Merci pour ces précisions.