Salut a tous,
Je ne comprend pas cette expression, est ce que quelqu'un peut m'expliquer svp?
Code:size++[result] = c
Version imprimable
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 à:
SalutationsCode:
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 */
Thierry
Ou plus simplement:
Code:
1
2 result[size] = c; size++;
Autant pour moi, c'est plus lisble!!!Citation:
Envoyé par Médinoc
Thierry
merci pour votre aide
Celui qui écrit du code comme ça mérite le miel et les fourmis rouges.Citation:
Envoyé par Pitou5464
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.
C'est défini dans la normeCitation:
Envoyé par InOCamlWeTrust
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).
Il n'y a pas de changement sur le fond. Ce genre de choses a toujours été autorisé.Citation:
Envoyé par InOCamlWeTrust
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++).Citation:
La définition des points de séquence est d'ailleurs assez claire (annexe 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
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
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 Jean-Marc.Bourguet
Si je me reporte au paragraphe 6.8.3, je vois ceci :Citation:
Envoyé par Standard du C, Annexe C
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 !) :Citation:
Envoyé par Standard du C, paragraphe 6.8.3
Si quelqu'un voit où je me trompe, merci de me le faire remarquer, car je suis vraissemblablement dans l'erreur.Code:
1
2
3 /* x et y sont des int */ x = (y = 7) + 4;
Tu avais écrit:Citation:
Envoyé par InOCamlWeTrust
J'infirmais ton affirmation. Il n'y a pas eu d'évolution importante entreCitation:
Il semblerait que la dernière norme (si c'est bien celle-ci) soit
plus permissive que la norme ANSI.
C90 et C99 sur ce point.
C'est normal, les subtilités échappent à beaucoup de monde. Je ne prétendsCitation:
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 :
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
la présence du point de séquencement entre e2 et e3 n'a aucune influenceCode:f(e1, e2 &&e3);
sur l'évaluation de e1.
Pourquoi? Il y a un point de séquencement à la fin de l'expression, çaCitation:
J'en déduis que ce genre d'expression contient un et un seul point
de séquence,
n'empèche pas qu'il puisse en avoir ailleurs.
Pourquoi? Ce qui est interdit c'est de modifier plusieurs fois le mêmeCitation:
avec deux effets de bord, qui ne serait donc pas autorisé en C-ANSI
(mais dont les codes de Knuth en sont bourrés !) :
objet ou de modifier et de lire le même objet quand la lecture ne sert pas
à déterminer la valeur écrite.
Il y a effectivement un seul point de séquencement et deux écritures dansCitation:
Code:
1
2
3 /* x et y sont des int */ x = (y = 7) + 4;
des objets différents.
Si tu écris:
on a un comportement indéfini si x et y sont des pointeurs vers le mêmeCode:*x = (*y = 7) + 4;
objet.
Si tu écris:
on a un comportement indéfini si y pointe vers x ou si y pointe vers z.Code:x = (*y = 7) + 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...
... est-il ANSI ?Code:
1
2 x = (y = 7) + 4;
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.
Par contre, pour ça...Citation:
Envoyé par Jean-Marc.Bourguet
... j'avais compris à la première lecture, je pense que le document est assez clair sur ce point :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.
Citation:
Envoyé par Standard du C, 5.1.2.3
Oui. Si ce n'était pas permis, l'utilisation des opérateurs ++ et -- serait fortement restreinte.Citation:
Envoyé par InOCamlWeTrust
Je ne vois pas d'autres cas où l'exécution de ces expressions causerait un comportement indéfini.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.
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.Citation:
Par contre, pour ça...
... j'avais compris à la première lecture, je pense que le document est assez clair sur ce point :
Merci pour ces précisions.