Je viens de tomber sur un message de Michel, d'il y a un mois, dont
voici un extrait :
> From: "Michel Michaud" <mm@gdzid.com>
> Subject: Re: buffer et std::vector<char> passage de l'un a l'autre
> Message-ID: <pQnHa.816$5d.225371@news20.bellglobal.com>
> Date: Mon, 16 Jun 2003 14:16:52 -0400
> Avec
> vector<char> v(taille);
> &v[0] est un char* qui peut être passé aux fonctions attendant un
> char[]/char*. La norme ne dit pas explicitement que les char sont
> contigus, mais c'est un fait et il y a une correction à la norme qui
> l'indique aussi.
J'avais toujours entendu dire que la contigüités des éléments d'un
vecteur était garantie. Apparemment non. Pour ce qui est de la
correction à la norme, je suppose que tu parlais d'un DR. En as-tu la
référence, stp ?
| Gabriel Dos Reis writes: | | |> Fabien LE LEZ writes: | | |> | On 10 Jul 2003 06:43:08 -0700, (drkm) wrote: | | |> | >Cela s'approche d'une garantie, sans en être réellement | |> | >une. | | |> | D'un autre côté, la présence dans la norme n'est pas | |> | non plus une garantie, puisqu'aucun compilo ne la suit à 100 | |> | % | | |> Cela est une affirmation de portée _générale_. Mais dans | |> ce cas *spécifique*, peux-tu nommer une seule implémentation | |> qui ne suit pas le TC1 sur ce point ? | | Évidemment. Une fois n'est pas régle : on a normalisé la | pratique existante. Ce qui n'enlève rien de l'affirmation | générale -- la présence dans la norme n'est pas une garantie.
Comme tu as pu le constater -- j'espère que tu as compris le message avant d'y répondre -- je ne m'intéressais pas à l'affirmation genérale. Il y a un cas concret, spécifique sous les yeux, en discussion.
-- Gaby
James Kanze <kanze@alex.gabi-soft.fr> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| |> Fabien LE LEZ <gramster@gramster.com> writes:
|
| |> | On 10 Jul 2003 06:43:08 -0700, darkman_spam@yahoo.fr (drkm) wrote:
|
| |> | >Cela s'approche d'une garantie, sans en être réellement
| |> | >une.
|
| |> | D'un autre côté, la présence dans la norme n'est pas
| |> | non plus une garantie, puisqu'aucun compilo ne la suit à 100
| |> | %
|
| |> Cela est une affirmation de portée _générale_. Mais dans
| |> ce cas *spécifique*, peux-tu nommer une seule implémentation
| |> qui ne suit pas le TC1 sur ce point ?
|
| Évidemment. Une fois n'est pas régle : on a normalisé la
| pratique existante. Ce qui n'enlève rien de l'affirmation
| générale -- la présence dans la norme n'est pas une garantie.
Comme tu as pu le constater -- j'espère que tu as compris le message
avant d'y répondre -- je ne m'intéressais pas à l'affirmation genérale.
Il y a un cas concret, spécifique sous les yeux, en discussion.
| Gabriel Dos Reis writes: | | |> Fabien LE LEZ writes: | | |> | On 10 Jul 2003 06:43:08 -0700, (drkm) wrote: | | |> | >Cela s'approche d'une garantie, sans en être réellement | |> | >une. | | |> | D'un autre côté, la présence dans la norme n'est pas | |> | non plus une garantie, puisqu'aucun compilo ne la suit à 100 | |> | % | | |> Cela est une affirmation de portée _générale_. Mais dans | |> ce cas *spécifique*, peux-tu nommer une seule implémentation | |> qui ne suit pas le TC1 sur ce point ? | | Évidemment. Une fois n'est pas régle : on a normalisé la | pratique existante. Ce qui n'enlève rien de l'affirmation | générale -- la présence dans la norme n'est pas une garantie.
Comme tu as pu le constater -- j'espère que tu as compris le message avant d'y répondre -- je ne m'intéressais pas à l'affirmation genérale. Il y a un cas concret, spécifique sous les yeux, en discussion.
-- Gaby
Gabriel Dos Reis
James Kanze writes:
| Gabriel Dos Reis writes: | | |> "Michel Michaud" writes: | |> | Dans news:bekb66$ql7$, Christophe | | |> | > L'aspect "data() pourrait être utile" peut être | |> | > contré par "si tu as besoin de data(), ce n'est pas de | |> | > vector dont tu as besoin", au même titre que si tu as | |> | > besoin d'un acès direct, ce n'est pas d'une liste | |> | > chainée dont tu as besoin. | | |> | Sauf si on se dit que les std::vector doivent pouvoir être | |> | employés au lieu des t[]... | | |> Pour la plupart des utilisation de t[], c'est exactement pour | |> ça que std::vector a été proposé. | | Dans ce cas-là, pourquoi la dynamique ?
Pour des raisons similaires à celles pour lesquelles C99 a introduit les VLAs -- sauf que ceux qu'Alex a été plus visionnaire.
| Après tout, ça nuit | beaucoup à son utilité comme remplaceant de T[] dans certains | cas. | | Et j'espère que tu ne vas pas prétendre que c'est le seul but de | std::vector.
Si c'était le cas, je l'aurais bien écrit et je n'aurais pas dit « Pour la plupart des utilisation de t[] », n'est-il pas ?
-- Gaby
James Kanze <kanze@alex.gabi-soft.fr> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| |> "Michel Michaud" <mm@gdzid.com> writes:
| |> | Dans news:bekb66$ql7$1@news-reader4.wanadoo.fr, Christophe
|
| |> | > L'aspect "data() pourrait être utile" peut être
| |> | > contré par "si tu as besoin de data(), ce n'est pas de
| |> | > vector dont tu as besoin", au même titre que si tu as
| |> | > besoin d'un acès direct, ce n'est pas d'une liste
| |> | > chainée dont tu as besoin.
|
| |> | Sauf si on se dit que les std::vector doivent pouvoir être
| |> | employés au lieu des t[]...
|
| |> Pour la plupart des utilisation de t[], c'est exactement pour
| |> ça que std::vector a été proposé.
|
| Dans ce cas-là, pourquoi la dynamique ?
Pour des raisons similaires à celles pour lesquelles C99 a introduit
les VLAs -- sauf que ceux qu'Alex a été plus visionnaire.
| Après tout, ça nuit
| beaucoup à son utilité comme remplaceant de T[] dans certains
| cas.
|
| Et j'espère que tu ne vas pas prétendre que c'est le seul but de
| std::vector.
Si c'était le cas, je l'aurais bien écrit et je n'aurais pas dit
« Pour la plupart des utilisation de t[] », n'est-il pas ?
| Gabriel Dos Reis writes: | | |> "Michel Michaud" writes: | |> | Dans news:bekb66$ql7$, Christophe | | |> | > L'aspect "data() pourrait être utile" peut être | |> | > contré par "si tu as besoin de data(), ce n'est pas de | |> | > vector dont tu as besoin", au même titre que si tu as | |> | > besoin d'un acès direct, ce n'est pas d'une liste | |> | > chainée dont tu as besoin. | | |> | Sauf si on se dit que les std::vector doivent pouvoir être | |> | employés au lieu des t[]... | | |> Pour la plupart des utilisation de t[], c'est exactement pour | |> ça que std::vector a été proposé. | | Dans ce cas-là, pourquoi la dynamique ?
Pour des raisons similaires à celles pour lesquelles C99 a introduit les VLAs -- sauf que ceux qu'Alex a été plus visionnaire.
| Après tout, ça nuit | beaucoup à son utilité comme remplaceant de T[] dans certains | cas. | | Et j'espère que tu ne vas pas prétendre que c'est le seul but de | std::vector.
Si c'était le cas, je l'aurais bien écrit et je n'aurais pas dit « Pour la plupart des utilisation de t[] », n'est-il pas ?
-- Gaby
Gabriel Dos Reis
James Kanze writes:
| Gabriel Dos Reis writes: | | |> "Christophe Lephay" writes: | | |> | "Michel Michaud" a écrit dans le message de | |> | news:aLhPa.8902$ | |> | > Dans news:, | | |> | > >(Ce qui est évident, c'est que si ç'avait été | |> | > >l'intention, on lui aurait sans doute donné une fonction | |> | > >du genre data(), comme on a fait pour stirng.) | | |> | > Euh, ça ne serait pas le contraire ? Si on ne prévoyait | |> | > pas que les éléments soient contigus, une fonction | |> | > data() serait utile pour obtenir une version (copie) ayant ce | |> | > critère. On a data() dans std::string parce que &s[0] n'est | |> | > pas nécessairement un tableau contigu... non ? Si les | |> | > éléments sont contigus, &v[0] me semble tout à fait | |> | > suffisant et &s[0] le serait aussi. | | |> | D'un autre coté, on n'a pas de data() dans les list, set et | |> | compagnie. Si on ne souhaites pas leur attribuer cette | |> | sémantique de "contiguité", c'est qu'ils ne s'y prètent | |> | pas de manière efficace. De la même manière, ne pas | |> | fournir de data() dans vector pourrait signifier qu'il n'est pas | |> | garanti de pouvoir restituer les données contigues de | |> | manière efficace. | | |> Ce que cela signifierait concrètement est au mieux de | |> l'ignorance du pourquoi de std::vector. | | Disons plus honnêtement que cela signifierait de l'ignorance sur le | pourquoi des opinions de Gabriel Dos Reis sur le pourquoi de | std::vector.
Ce qui en dit long sur la bonne foi de James Kanze.
| |> Il n'a jamais fait un doute dans la tête de ceux qui ont | |> travaillé activement à l'adoption d'une partie de la STL | |> dans la norme qu'un std::vector<> devait garantir la | |> contiguité. | | C'est dommage, alors, qu'ils ne l'ont pas indiqué par écrit, | parce qu'il n'y a absolument rien dans la norme qui en donnerait cette | idée.
Tout le monde est d'accord sur ce point. La syntaxe ne fait pas tout.
-- Gaby
James Kanze <kanze@alex.gabi-soft.fr> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| |> "Christophe Lephay" <christophe-lephay@wanadoo.fr> writes:
|
| |> | "Michel Michaud" <mm@gdzid.com> a écrit dans le message de
| |> | news:aLhPa.8902$ru2.872804@news20.bellglobal.com...
| |> | > Dans news:d6652001.0307100850.19d74817@posting.google.com,
|
| |> | > >(Ce qui est évident, c'est que si ç'avait été
| |> | > >l'intention, on lui aurait sans doute donné une fonction
| |> | > >du genre data(), comme on a fait pour stirng.)
|
| |> | > Euh, ça ne serait pas le contraire ? Si on ne prévoyait
| |> | > pas que les éléments soient contigus, une fonction
| |> | > data() serait utile pour obtenir une version (copie) ayant ce
| |> | > critère. On a data() dans std::string parce que &s[0] n'est
| |> | > pas nécessairement un tableau contigu... non ? Si les
| |> | > éléments sont contigus, &v[0] me semble tout à fait
| |> | > suffisant et &s[0] le serait aussi.
|
| |> | D'un autre coté, on n'a pas de data() dans les list, set et
| |> | compagnie. Si on ne souhaites pas leur attribuer cette
| |> | sémantique de "contiguité", c'est qu'ils ne s'y prètent
| |> | pas de manière efficace. De la même manière, ne pas
| |> | fournir de data() dans vector pourrait signifier qu'il n'est pas
| |> | garanti de pouvoir restituer les données contigues de
| |> | manière efficace.
|
| |> Ce que cela signifierait concrètement est au mieux de
| |> l'ignorance du pourquoi de std::vector.
|
| Disons plus honnêtement que cela signifierait de l'ignorance sur le
| pourquoi des opinions de Gabriel Dos Reis sur le pourquoi de
| std::vector.
Ce qui en dit long sur la bonne foi de James Kanze.
| |> Il n'a jamais fait un doute dans la tête de ceux qui ont
| |> travaillé activement à l'adoption d'une partie de la STL
| |> dans la norme qu'un std::vector<> devait garantir la
| |> contiguité.
|
| C'est dommage, alors, qu'ils ne l'ont pas indiqué par écrit,
| parce qu'il n'y a absolument rien dans la norme qui en donnerait cette
| idée.
Tout le monde est d'accord sur ce point. La syntaxe ne fait pas tout.
| Gabriel Dos Reis writes: | | |> "Christophe Lephay" writes: | | |> | "Michel Michaud" a écrit dans le message de | |> | news:aLhPa.8902$ | |> | > Dans news:, | | |> | > >(Ce qui est évident, c'est que si ç'avait été | |> | > >l'intention, on lui aurait sans doute donné une fonction | |> | > >du genre data(), comme on a fait pour stirng.) | | |> | > Euh, ça ne serait pas le contraire ? Si on ne prévoyait | |> | > pas que les éléments soient contigus, une fonction | |> | > data() serait utile pour obtenir une version (copie) ayant ce | |> | > critère. On a data() dans std::string parce que &s[0] n'est | |> | > pas nécessairement un tableau contigu... non ? Si les | |> | > éléments sont contigus, &v[0] me semble tout à fait | |> | > suffisant et &s[0] le serait aussi. | | |> | D'un autre coté, on n'a pas de data() dans les list, set et | |> | compagnie. Si on ne souhaites pas leur attribuer cette | |> | sémantique de "contiguité", c'est qu'ils ne s'y prètent | |> | pas de manière efficace. De la même manière, ne pas | |> | fournir de data() dans vector pourrait signifier qu'il n'est pas | |> | garanti de pouvoir restituer les données contigues de | |> | manière efficace. | | |> Ce que cela signifierait concrètement est au mieux de | |> l'ignorance du pourquoi de std::vector. | | Disons plus honnêtement que cela signifierait de l'ignorance sur le | pourquoi des opinions de Gabriel Dos Reis sur le pourquoi de | std::vector.
Ce qui en dit long sur la bonne foi de James Kanze.
| |> Il n'a jamais fait un doute dans la tête de ceux qui ont | |> travaillé activement à l'adoption d'une partie de la STL | |> dans la norme qu'un std::vector<> devait garantir la | |> contiguité. | | C'est dommage, alors, qu'ils ne l'ont pas indiqué par écrit, | parce qu'il n'y a absolument rien dans la norme qui en donnerait cette | idée.
Tout le monde est d'accord sur ce point. La syntaxe ne fait pas tout.
-- Gaby
Gabriel Dos Reis
James Kanze writes:
| Gabriel Dos Reis writes: | | |> James Kanze writes: | | |> | C'est une intention qu'on a bien trouvé après coup, non ? | | |> Non. | | |> | Ou peut-être Gaby pourrait nous trouver des papiers où on | |> | en a parlé avant. | | |> À quoi bon ? puisque pour toi, ce sera une citation hors | |> contexte. Même si on Alex donnait son plein accord et qu'on | |> publiait ce qu'il dit ici, ce sera pour toi une citation hors | |> contexte. | | Ne sois pas de mauvaise fois.
Pouf. Regarde-toi dans la glace et essaie de suivre ton propre conseil.
| C'est assez évident que ce n'était | pas comment l'entendait tout le monde, mais j'aimerais simplement de | l'évidence qu'il y avait même une seule personne dont | l'intention était que les vector soient obligatoirement | contigu.
Ne sois pas ridicule, tu as accès aux archives. Regarde les.
Une autre évidence, d'un point de vue pragamtique est la constance avec laquelle BS a toujours conseiller de préférer les std::vector aux T[] depuis la publication de TC++PL3 en 1997. Là encore, tu peux le lire -- j'ai déjà parié avec ma souris que tu rejèteras l'idée.
| |> C'est l'une des raisons de plus pour que je considère ton | |> affirmation comme un delire de plus, et que tu n'admettras jamais | |> son caractère diffamatoire. | | Si la vérité est diffamatoire, qu'il en soit ainsi.
Là on atteint le fond. N'en ajoute plus.
| En fait, je | crois que le fait que le comité se compose d'êtres humains, et | se comporte comme un groupe d'êtres humains, ne soit pas | particulièrement diffamatoire.
Clairement ce n'était pas l'affirmation sous discussion.
-- Gaby
James Kanze <kanze@alex.gabi-soft.fr> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| |> James Kanze <kanze@alex.gabi-soft.fr> writes:
|
| |> | C'est une intention qu'on a bien trouvé après coup, non ?
|
| |> Non.
|
| |> | Ou peut-être Gaby pourrait nous trouver des papiers où on
| |> | en a parlé avant.
|
| |> À quoi bon ? puisque pour toi, ce sera une citation hors
| |> contexte. Même si on Alex donnait son plein accord et qu'on
| |> publiait ce qu'il dit ici, ce sera pour toi une citation hors
| |> contexte.
|
| Ne sois pas de mauvaise fois.
Pouf. Regarde-toi dans la glace et essaie de suivre ton propre conseil.
| C'est assez évident que ce n'était
| pas comment l'entendait tout le monde, mais j'aimerais simplement de
| l'évidence qu'il y avait même une seule personne dont
| l'intention était que les vector soient obligatoirement
| contigu.
Ne sois pas ridicule, tu as accès aux archives. Regarde les.
Une autre évidence, d'un point de vue pragamtique est la constance
avec laquelle BS a toujours conseiller de préférer les std::vector aux
T[] depuis la publication de TC++PL3 en 1997. Là encore, tu peux le
lire -- j'ai déjà parié avec ma souris que tu rejèteras l'idée.
| |> C'est l'une des raisons de plus pour que je considère ton
| |> affirmation comme un delire de plus, et que tu n'admettras jamais
| |> son caractère diffamatoire.
|
| Si la vérité est diffamatoire, qu'il en soit ainsi.
Là on atteint le fond. N'en ajoute plus.
| En fait, je
| crois que le fait que le comité se compose d'êtres humains, et
| se comporte comme un groupe d'êtres humains, ne soit pas
| particulièrement diffamatoire.
Clairement ce n'était pas l'affirmation sous discussion.
| Gabriel Dos Reis writes: | | |> James Kanze writes: | | |> | C'est une intention qu'on a bien trouvé après coup, non ? | | |> Non. | | |> | Ou peut-être Gaby pourrait nous trouver des papiers où on | |> | en a parlé avant. | | |> À quoi bon ? puisque pour toi, ce sera une citation hors | |> contexte. Même si on Alex donnait son plein accord et qu'on | |> publiait ce qu'il dit ici, ce sera pour toi une citation hors | |> contexte. | | Ne sois pas de mauvaise fois.
Pouf. Regarde-toi dans la glace et essaie de suivre ton propre conseil.
| C'est assez évident que ce n'était | pas comment l'entendait tout le monde, mais j'aimerais simplement de | l'évidence qu'il y avait même une seule personne dont | l'intention était que les vector soient obligatoirement | contigu.
Ne sois pas ridicule, tu as accès aux archives. Regarde les.
Une autre évidence, d'un point de vue pragamtique est la constance avec laquelle BS a toujours conseiller de préférer les std::vector aux T[] depuis la publication de TC++PL3 en 1997. Là encore, tu peux le lire -- j'ai déjà parié avec ma souris que tu rejèteras l'idée.
| |> C'est l'une des raisons de plus pour que je considère ton | |> affirmation comme un delire de plus, et que tu n'admettras jamais | |> son caractère diffamatoire. | | Si la vérité est diffamatoire, qu'il en soit ainsi.
Là on atteint le fond. N'en ajoute plus.
| En fait, je | crois que le fait que le comité se compose d'êtres humains, et | se comporte comme un groupe d'êtres humains, ne soit pas | particulièrement diffamatoire.
Clairement ce n'était pas l'affirmation sous discussion.
-- Gaby
Gabriel Dos Reis
James Kanze writes:
| Gabriel Dos Reis writes: | | |> writes: | | |> | "Michel Michaud" wrote in message | |> | news:<aLhPa.8902$... | |> | > Dans news:, | |> | > > "Alain Naigeon" wrote in message | |> | > > news:<3f0d2ae3$0$5248$... | |> | > >> Est-ce qu'il y a quoi que ce soit dans l'interface de | |> | > >> std::vector qui suppose cette contigüité ? | | |> | > > Il n'y en a pas la moindre suggestion dans la norme qu'il y | |> | > > a une exigence de contiguïté. Par la suite, en | |> | > > revanche, certains ont décidé que ce serait bien, | |> | > > précisement pour des questions d'interface avec C, et on | |> | > > a inventé que c'était l'intention, et | | |> | > Oh ! C'est toute une accusation ça ! Ça vaut la peine de | |> | > poser la question sur comp.std.c++... Est-ce que je peux te | |> | > citer ? | | |> | Pour quoi faire ? | | |> juste pour confronter à la réalité concrète. Mais je | |> présume que ce n'est pas la peine, puisque cela fait pschitttt | |> tout seul. | | Qu'il le fasse s'il veuille. Je ne vois pas où ça changerait | quelque chose. En attendant, j'aimerais bien voir une indication que | quelqu'un (n'importe qui) y avait pensé avant que la question soit | soulevée.
Et pourquoi refuses-tu de regarder les archives ?
| |> | Ce n'est pas une accusation, mais une constatation. | | |> ah?! un instant j'ai cru que c'était une de tes figures de | |> style que tu appelles « hyperbole ». | | |> | Le comité est un organisme politique. | | |> Il est à gauche ? à droite ? au cecntre ? démocrate ? | |> républicain ? | | Tu connais la signification historique du mot politique, tel qu'on | l'emploie, par exemple, dans la philosophie ?
Ben non, puisque je t'ai attendu pour que tu me l'expliques.
[...]
| |> | Après la publication de la norme, on s'était rendu compte | |> | qu'il y avait un cas d'utilisation dont personne n'avait | |> | pensé, et dont qui n'était | | |> Plus exactement, on s'est rendu compte qu'on a oublié | |> d'écrire noir sur blanc, une garantie importante qui était | |> implicite dans la tête de ceux qui ont activement contribué | |> à l'adoptiond e std::vector dans la norme. | | C'est ce qu'on a dit. Mais ça veut dire quoi « implicite dans la | tête de ceux qui ont activement contribué ... » ? Qu'ils y | ont consciemment pensé ?
que cela leur était évident.
L'un d'eux a constamment conseillé de préférer std::vector<T> aux T[].
[...]
| |> C'est fascinant lorsque tu réécris l'histoire. | | Dans ce cas-ci, je ne démande que d'y croire ; je suis pour la | contiguïté, moi aussi. Seulement, d'après toute | l'évidence.
La question n'est pas si tu es pour la contiguité ou non. La question concerne l'assertion diffamatoire que tu as faite.
| Tu vois, moi, je ne prends pas mes souhaits pour la réalité.
et pourtant, c'est exactement ce que tu fais.
-- Gaby
James Kanze <kanze@alex.gabi-soft.fr> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| |> kanze@gabi-soft.fr writes:
|
| |> | "Michel Michaud" <mm@gdzid.com> wrote in message
| |> | news:<aLhPa.8902$ru2.872804@news20.bellglobal.com>...
| |> | > Dans news:d6652001.0307100850.19d74817@posting.google.com,
| |> | > > "Alain Naigeon" <anaigeon@free.fr> wrote in message
| |> | > > news:<3f0d2ae3$0$5248$626a54ce@news.free.fr>...
| |> | > >> Est-ce qu'il y a quoi que ce soit dans l'interface de
| |> | > >> std::vector qui suppose cette contigüité ?
|
| |> | > > Il n'y en a pas la moindre suggestion dans la norme qu'il y
| |> | > > a une exigence de contiguïté. Par la suite, en
| |> | > > revanche, certains ont décidé que ce serait bien,
| |> | > > précisement pour des questions d'interface avec C, et on
| |> | > > a inventé que c'était l'intention, et
|
| |> | > Oh ! C'est toute une accusation ça ! Ça vaut la peine de
| |> | > poser la question sur comp.std.c++... Est-ce que je peux te
| |> | > citer ?
|
| |> | Pour quoi faire ?
|
| |> juste pour confronter à la réalité concrète. Mais je
| |> présume que ce n'est pas la peine, puisque cela fait pschitttt
| |> tout seul.
|
| Qu'il le fasse s'il veuille. Je ne vois pas où ça changerait
| quelque chose. En attendant, j'aimerais bien voir une indication que
| quelqu'un (n'importe qui) y avait pensé avant que la question soit
| soulevée.
Et pourquoi refuses-tu de regarder les archives ?
| |> | Ce n'est pas une accusation, mais une constatation.
|
| |> ah?! un instant j'ai cru que c'était une de tes figures de
| |> style que tu appelles « hyperbole ».
|
| |> | Le comité est un organisme politique.
|
| |> Il est à gauche ? à droite ? au cecntre ? démocrate ?
| |> républicain ?
|
| Tu connais la signification historique du mot politique, tel qu'on
| l'emploie, par exemple, dans la philosophie ?
Ben non, puisque je t'ai attendu pour que tu me l'expliques.
[...]
| |> | Après la publication de la norme, on s'était rendu compte
| |> | qu'il y avait un cas d'utilisation dont personne n'avait
| |> | pensé, et dont qui n'était
|
| |> Plus exactement, on s'est rendu compte qu'on a oublié
| |> d'écrire noir sur blanc, une garantie importante qui était
| |> implicite dans la tête de ceux qui ont activement contribué
| |> à l'adoptiond e std::vector dans la norme.
|
| C'est ce qu'on a dit. Mais ça veut dire quoi « implicite dans la
| tête de ceux qui ont activement contribué ... » ? Qu'ils y
| ont consciemment pensé ?
que cela leur était évident.
L'un d'eux a constamment conseillé de préférer std::vector<T> aux T[].
[...]
| |> C'est fascinant lorsque tu réécris l'histoire.
|
| Dans ce cas-ci, je ne démande que d'y croire ; je suis pour la
| contiguïté, moi aussi. Seulement, d'après toute
| l'évidence.
La question n'est pas si tu es pour la contiguité ou non. La question
concerne l'assertion diffamatoire que tu as faite.
| Tu vois, moi, je ne prends pas mes souhaits pour la réalité.
| Gabriel Dos Reis writes: | | |> writes: | | |> | "Michel Michaud" wrote in message | |> | news:<aLhPa.8902$... | |> | > Dans news:, | |> | > > "Alain Naigeon" wrote in message | |> | > > news:<3f0d2ae3$0$5248$... | |> | > >> Est-ce qu'il y a quoi que ce soit dans l'interface de | |> | > >> std::vector qui suppose cette contigüité ? | | |> | > > Il n'y en a pas la moindre suggestion dans la norme qu'il y | |> | > > a une exigence de contiguïté. Par la suite, en | |> | > > revanche, certains ont décidé que ce serait bien, | |> | > > précisement pour des questions d'interface avec C, et on | |> | > > a inventé que c'était l'intention, et | | |> | > Oh ! C'est toute une accusation ça ! Ça vaut la peine de | |> | > poser la question sur comp.std.c++... Est-ce que je peux te | |> | > citer ? | | |> | Pour quoi faire ? | | |> juste pour confronter à la réalité concrète. Mais je | |> présume que ce n'est pas la peine, puisque cela fait pschitttt | |> tout seul. | | Qu'il le fasse s'il veuille. Je ne vois pas où ça changerait | quelque chose. En attendant, j'aimerais bien voir une indication que | quelqu'un (n'importe qui) y avait pensé avant que la question soit | soulevée.
Et pourquoi refuses-tu de regarder les archives ?
| |> | Ce n'est pas une accusation, mais une constatation. | | |> ah?! un instant j'ai cru que c'était une de tes figures de | |> style que tu appelles « hyperbole ». | | |> | Le comité est un organisme politique. | | |> Il est à gauche ? à droite ? au cecntre ? démocrate ? | |> républicain ? | | Tu connais la signification historique du mot politique, tel qu'on | l'emploie, par exemple, dans la philosophie ?
Ben non, puisque je t'ai attendu pour que tu me l'expliques.
[...]
| |> | Après la publication de la norme, on s'était rendu compte | |> | qu'il y avait un cas d'utilisation dont personne n'avait | |> | pensé, et dont qui n'était | | |> Plus exactement, on s'est rendu compte qu'on a oublié | |> d'écrire noir sur blanc, une garantie importante qui était | |> implicite dans la tête de ceux qui ont activement contribué | |> à l'adoptiond e std::vector dans la norme. | | C'est ce qu'on a dit. Mais ça veut dire quoi « implicite dans la | tête de ceux qui ont activement contribué ... » ? Qu'ils y | ont consciemment pensé ?
que cela leur était évident.
L'un d'eux a constamment conseillé de préférer std::vector<T> aux T[].
[...]
| |> C'est fascinant lorsque tu réécris l'histoire. | | Dans ce cas-ci, je ne démande que d'y croire ; je suis pour la | contiguïté, moi aussi. Seulement, d'après toute | l'évidence.
La question n'est pas si tu es pour la contiguité ou non. La question concerne l'assertion diffamatoire que tu as faite.
| Tu vois, moi, je ne prends pas mes souhaits pour la réalité.
et pourtant, c'est exactement ce que tu fais.
-- Gaby
James Kanze
Gabriel Dos Reis writes:
|> James Kanze writes:
[...]
|> | C'est assez évident que ce n'était pas comment l'entendait |> | tout le monde, mais j'aimerais simplement de l'évidence qu'il |> | y avait même une seule personne dont l'intention était que |> | les vector soient obligatoirement contigu.
|> Ne sois pas ridicule, tu as accès aux archives. Regarde les.
D'abord, je n'ai pas accès aux archives. Pas actuellement, en tout cas. Deuxièmement, ce que j'ai dit est trivialement vrai -- tout le monde ne s'entendait pas que vector soit obligatoirement contigu. Triviallement, parce que je connais au moins une personne qui ne s'en doutait pas du tout que ce soit une exigence -- moi-même.
Mais ce que je démande, c'est des preuves (assez lache, d'ailleurs), qu'il y avait des gens qui avaient consciemment l'intention que ce soit une obligation. (Qu'il y avait des gens qui n'en avaient pas du tout pensé, je le crois bien.)
|> Une autre évidence, d'un point de vue pragamtique est la |> constance avec laquelle BS a toujours conseiller de préférer |> les std::vector aux T[] depuis la publication de TC++PL3 en 1997.
Moi aussi, j'ai toujours dit de préférer les std::vector aux T[], depuis qu'ils font partie de la norme. Tout en sachant très bien que la contiguïté n'était pas garantie. Le mot opératif, c'est toujours « préférer ». Pas de les utiliser quand ce n'était pas possible.
Une des raisons pourquoi j'ai accepté la fiction de l'intention aussi allegrément, c'est bien que j'y ai vu une possibilité de les utiliser encore plus qu'avant.
|> Là encore, tu peux le lire -- j'ai déjà parié avec ma |> souris que tu rejèteras l'idée.
En fait, je suis tout à fait d'accord avec Stroustrup ici.
|> | |> C'est l'une des raisons de plus pour que je considère ton |> | |> affirmation comme un delire de plus, et que tu n'admettras |> | |> jamais son caractère diffamatoire.
|> | Si la vérité est diffamatoire, qu'il en soit ainsi.
|> Là on atteint le fond. N'en ajoute plus.
C'est quoi, au fond, que tu n'aimes pas ? La vérité ?
|> | En fait, je crois que le fait que le comité se compose |> | d'êtres humains, et se comporte comme un groupe d'êtres |> | humains, ne soit pas particulièrement diffamatoire.
|> Clairement ce n'était pas l'affirmation sous discussion.
L'affirmation, c'est que le comité a trouvé un moyen d'améliorer std::vector, à un coût quasi-null, et qu'il en a profité. Qu'il a fallu masquer un peu d'innovation dans les spécifications (mais qui n'en était pas dans les implémentations) derrière des « intentions » non exprimées, c'est une astuce que je ne critique pas.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|> James Kanze <kanze@alex.gabi-soft.fr> writes:
[...]
|> | C'est assez évident que ce n'était pas comment l'entendait
|> | tout le monde, mais j'aimerais simplement de l'évidence qu'il
|> | y avait même une seule personne dont l'intention était que
|> | les vector soient obligatoirement contigu.
|> Ne sois pas ridicule, tu as accès aux archives. Regarde les.
D'abord, je n'ai pas accès aux archives. Pas actuellement, en tout
cas. Deuxièmement, ce que j'ai dit est trivialement vrai -- tout le
monde ne s'entendait pas que vector soit obligatoirement
contigu. Triviallement, parce que je connais au moins une personne qui
ne s'en doutait pas du tout que ce soit une exigence -- moi-même.
Mais ce que je démande, c'est des preuves (assez lache,
d'ailleurs), qu'il y avait des gens qui avaient consciemment
l'intention que ce soit une obligation. (Qu'il y avait des gens qui
n'en avaient pas du tout pensé, je le crois bien.)
|> Une autre évidence, d'un point de vue pragamtique est la
|> constance avec laquelle BS a toujours conseiller de préférer
|> les std::vector aux T[] depuis la publication de TC++PL3 en 1997.
Moi aussi, j'ai toujours dit de préférer les std::vector aux
T[], depuis qu'ils font partie de la norme. Tout en sachant très
bien que la contiguïté n'était pas garantie. Le mot
opératif, c'est toujours « préférer ». Pas de les
utiliser quand ce n'était pas possible.
Une des raisons pourquoi j'ai accepté la fiction de l'intention
aussi allegrément, c'est bien que j'y ai vu une possibilité de
les utiliser encore plus qu'avant.
|> Là encore, tu peux le lire -- j'ai déjà parié avec ma
|> souris que tu rejèteras l'idée.
En fait, je suis tout à fait d'accord avec Stroustrup ici.
|> | |> C'est l'une des raisons de plus pour que je considère ton
|> | |> affirmation comme un delire de plus, et que tu n'admettras
|> | |> jamais son caractère diffamatoire.
|> | Si la vérité est diffamatoire, qu'il en soit ainsi.
|> Là on atteint le fond. N'en ajoute plus.
C'est quoi, au fond, que tu n'aimes pas ? La vérité ?
|> | En fait, je crois que le fait que le comité se compose
|> | d'êtres humains, et se comporte comme un groupe d'êtres
|> | humains, ne soit pas particulièrement diffamatoire.
|> Clairement ce n'était pas l'affirmation sous discussion.
L'affirmation, c'est que le comité a trouvé un moyen
d'améliorer std::vector, à un coût quasi-null, et qu'il en a
profité. Qu'il a fallu masquer un peu d'innovation dans les
spécifications (mais qui n'en était pas dans les
implémentations) derrière des « intentions » non
exprimées, c'est une astuce que je ne critique pas.
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> | C'est assez évident que ce n'était pas comment l'entendait |> | tout le monde, mais j'aimerais simplement de l'évidence qu'il |> | y avait même une seule personne dont l'intention était que |> | les vector soient obligatoirement contigu.
|> Ne sois pas ridicule, tu as accès aux archives. Regarde les.
D'abord, je n'ai pas accès aux archives. Pas actuellement, en tout cas. Deuxièmement, ce que j'ai dit est trivialement vrai -- tout le monde ne s'entendait pas que vector soit obligatoirement contigu. Triviallement, parce que je connais au moins une personne qui ne s'en doutait pas du tout que ce soit une exigence -- moi-même.
Mais ce que je démande, c'est des preuves (assez lache, d'ailleurs), qu'il y avait des gens qui avaient consciemment l'intention que ce soit une obligation. (Qu'il y avait des gens qui n'en avaient pas du tout pensé, je le crois bien.)
|> Une autre évidence, d'un point de vue pragamtique est la |> constance avec laquelle BS a toujours conseiller de préférer |> les std::vector aux T[] depuis la publication de TC++PL3 en 1997.
Moi aussi, j'ai toujours dit de préférer les std::vector aux T[], depuis qu'ils font partie de la norme. Tout en sachant très bien que la contiguïté n'était pas garantie. Le mot opératif, c'est toujours « préférer ». Pas de les utiliser quand ce n'était pas possible.
Une des raisons pourquoi j'ai accepté la fiction de l'intention aussi allegrément, c'est bien que j'y ai vu une possibilité de les utiliser encore plus qu'avant.
|> Là encore, tu peux le lire -- j'ai déjà parié avec ma |> souris que tu rejèteras l'idée.
En fait, je suis tout à fait d'accord avec Stroustrup ici.
|> | |> C'est l'une des raisons de plus pour que je considère ton |> | |> affirmation comme un delire de plus, et que tu n'admettras |> | |> jamais son caractère diffamatoire.
|> | Si la vérité est diffamatoire, qu'il en soit ainsi.
|> Là on atteint le fond. N'en ajoute plus.
C'est quoi, au fond, que tu n'aimes pas ? La vérité ?
|> | En fait, je crois que le fait que le comité se compose |> | d'êtres humains, et se comporte comme un groupe d'êtres |> | humains, ne soit pas particulièrement diffamatoire.
|> Clairement ce n'était pas l'affirmation sous discussion.
L'affirmation, c'est que le comité a trouvé un moyen d'améliorer std::vector, à un coût quasi-null, et qu'il en a profité. Qu'il a fallu masquer un peu d'innovation dans les spécifications (mais qui n'en était pas dans les implémentations) derrière des « intentions » non exprimées, c'est une astuce que je ne critique pas.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> | |> | >Cela s'approche d'une garantie, sans en être |> | |> | >réellement une.
|> | |> | D'un autre côté, la présence dans la norme n'est |> | |> | pas non plus une garantie, puisqu'aucun compilo ne la suit |> | |> | à 100 %
|> | |> Cela est une affirmation de portée _générale_. Mais |> | |> dans ce cas *spécifique*, peux-tu nommer une seule |> | |> implémentation qui ne suit pas le TC1 sur ce point ?
|> | Évidemment. Une fois n'est pas régle : on a normalisé |> | la pratique existante. Ce qui n'enlève rien de l'affirmation |> | générale -- la présence dans la norme n'est pas une |> | garantie.
|> Comme tu as pu le constater -- j'espère que tu as compris le |> message avant d'y répondre -- je ne m'intéressais pas à |> l'affirmation genérale. Il y a un cas concret, spécifique |> sous les yeux, en discussion.
Comme j'ai pu constater, tu as préféré parler à côté plutôt que de répondre à ce que le posteur avait écrit. Ce que Fabien a dit est 100% correct. Ce que tu dis aussi, mais ta façon à le formuler en question laisse supposer que tu voulais contradire Fabien.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|> James Kanze <kanze@alex.gabi-soft.fr> writes:
|> | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|> | |> Fabien LE LEZ <gramster@gramster.com> writes:
|> | |> | >Cela s'approche d'une garantie, sans en être
|> | |> | >réellement une.
|> | |> | D'un autre côté, la présence dans la norme n'est
|> | |> | pas non plus une garantie, puisqu'aucun compilo ne la suit
|> | |> | à 100 %
|> | |> Cela est une affirmation de portée _générale_. Mais
|> | |> dans ce cas *spécifique*, peux-tu nommer une seule
|> | |> implémentation qui ne suit pas le TC1 sur ce point ?
|> | Évidemment. Une fois n'est pas régle : on a normalisé
|> | la pratique existante. Ce qui n'enlève rien de l'affirmation
|> | générale -- la présence dans la norme n'est pas une
|> | garantie.
|> Comme tu as pu le constater -- j'espère que tu as compris le
|> message avant d'y répondre -- je ne m'intéressais pas à
|> l'affirmation genérale. Il y a un cas concret, spécifique
|> sous les yeux, en discussion.
Comme j'ai pu constater, tu as préféré parler à côté
plutôt que de répondre à ce que le posteur avait écrit. Ce
que Fabien a dit est 100% correct. Ce que tu dis aussi, mais ta
façon à le formuler en question laisse supposer que tu voulais
contradire Fabien.
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> | |> | >Cela s'approche d'une garantie, sans en être |> | |> | >réellement une.
|> | |> | D'un autre côté, la présence dans la norme n'est |> | |> | pas non plus une garantie, puisqu'aucun compilo ne la suit |> | |> | à 100 %
|> | |> Cela est une affirmation de portée _générale_. Mais |> | |> dans ce cas *spécifique*, peux-tu nommer une seule |> | |> implémentation qui ne suit pas le TC1 sur ce point ?
|> | Évidemment. Une fois n'est pas régle : on a normalisé |> | la pratique existante. Ce qui n'enlève rien de l'affirmation |> | générale -- la présence dans la norme n'est pas une |> | garantie.
|> Comme tu as pu le constater -- j'espère que tu as compris le |> message avant d'y répondre -- je ne m'intéressais pas à |> l'affirmation genérale. Il y a un cas concret, spécifique |> sous les yeux, en discussion.
Comme j'ai pu constater, tu as préféré parler à côté plutôt que de répondre à ce que le posteur avait écrit. Ce que Fabien a dit est 100% correct. Ce que tu dis aussi, mais ta façon à le formuler en question laisse supposer que tu voulais contradire Fabien.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
James Kanze
Gabriel Dos Reis writes:
|> James Kanze writes:
|> | C'est dommage, alors, qu'ils ne l'ont pas indiqué par |> | écrit, parce qu'il n'y a absolument rien dans la norme qui en |> | donnerait cette idée.
|> Tout le monde est d'accord sur ce point. La syntaxe ne fait pas |> tout.
Il n'y a pas que du syntaxe dans la norme.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|> James Kanze <kanze@alex.gabi-soft.fr> writes:
|> | C'est dommage, alors, qu'ils ne l'ont pas indiqué par
|> | écrit, parce qu'il n'y a absolument rien dans la norme qui en
|> | donnerait cette idée.
|> Tout le monde est d'accord sur ce point. La syntaxe ne fait pas
|> tout.
Il n'y a pas que du syntaxe dans la norme.
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> | C'est dommage, alors, qu'ils ne l'ont pas indiqué par |> | écrit, parce qu'il n'y a absolument rien dans la norme qui en |> | donnerait cette idée.
|> Tout le monde est d'accord sur ce point. La syntaxe ne fait pas |> tout.
Il n'y a pas que du syntaxe dans la norme.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Gabriel Dos Reis
James Kanze writes:
| Gabriel Dos Reis writes: | | |> James Kanze writes: | | |> | Gabriel Dos Reis writes: | | |> | |> Fabien LE LEZ writes: | | |> | |> | On 10 Jul 2003 06:43:08 -0700, (drkm) wrote: | | |> | |> | >Cela s'approche d'une garantie, sans en être | |> | |> | >réellement une. | | |> | |> | D'un autre côté, la présence dans la norme n'est | |> | |> | pas non plus une garantie, puisqu'aucun compilo ne la suit | |> | |> | à 100 % | | |> | |> Cela est une affirmation de portée _générale_. Mais | |> | |> dans ce cas *spécifique*, peux-tu nommer une seule | |> | |> implémentation qui ne suit pas le TC1 sur ce point ? | | |> | Évidemment. Une fois n'est pas régle : on a normalisé | |> | la pratique existante. Ce qui n'enlève rien de l'affirmation | |> | générale -- la présence dans la norme n'est pas une | |> | garantie. | | |> Comme tu as pu le constater -- j'espère que tu as compris le | |> message avant d'y répondre -- je ne m'intéressais pas à | |> l'affirmation genérale. Il y a un cas concret, spécifique | |> sous les yeux, en discussion. | | Comme j'ai pu constater, tu as préféré parler à côté | plutôt que de répondre à ce que le posteur avait écrit.
Pouf, il faut que tu reactualies tes capteurs sensoriels.
| Ce | que Fabien a dit est 100% correct. Ce que tu dis aussi, mais ta | façon à le formuler en question laisse supposer que tu voulais | contradire Fabien.
Comme je l'ai rappelé dans mon message, ce que Fabien dit est une affirmation d'ordre général, dont la validité ne m'intéresse pas. Ce qui m'intéressait c'était le cas spécifique sous discussion. Mais évidemment, j'aurais dû me douter que cela te passerait complètement inaperçu.
-- Gaby
James Kanze <kanze@alex.gabi-soft.fr> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| |> James Kanze <kanze@alex.gabi-soft.fr> writes:
|
| |> | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| |> | |> Fabien LE LEZ <gramster@gramster.com> writes:
|
| |> | |> | On 10 Jul 2003 06:43:08 -0700, darkman_spam@yahoo.fr (drkm) wrote:
|
| |> | |> | >Cela s'approche d'une garantie, sans en être
| |> | |> | >réellement une.
|
| |> | |> | D'un autre côté, la présence dans la norme n'est
| |> | |> | pas non plus une garantie, puisqu'aucun compilo ne la suit
| |> | |> | à 100 %
|
| |> | |> Cela est une affirmation de portée _générale_. Mais
| |> | |> dans ce cas *spécifique*, peux-tu nommer une seule
| |> | |> implémentation qui ne suit pas le TC1 sur ce point ?
|
| |> | Évidemment. Une fois n'est pas régle : on a normalisé
| |> | la pratique existante. Ce qui n'enlève rien de l'affirmation
| |> | générale -- la présence dans la norme n'est pas une
| |> | garantie.
|
| |> Comme tu as pu le constater -- j'espère que tu as compris le
| |> message avant d'y répondre -- je ne m'intéressais pas à
| |> l'affirmation genérale. Il y a un cas concret, spécifique
| |> sous les yeux, en discussion.
|
| Comme j'ai pu constater, tu as préféré parler à côté
| plutôt que de répondre à ce que le posteur avait écrit.
Pouf, il faut que tu reactualies tes capteurs sensoriels.
| Ce
| que Fabien a dit est 100% correct. Ce que tu dis aussi, mais ta
| façon à le formuler en question laisse supposer que tu voulais
| contradire Fabien.
Comme je l'ai rappelé dans mon message, ce que Fabien dit est une
affirmation d'ordre général, dont la validité ne m'intéresse pas. Ce qui
m'intéressait c'était le cas spécifique sous discussion. Mais
évidemment, j'aurais dû me douter que cela te passerait complètement
inaperçu.
| Gabriel Dos Reis writes: | | |> James Kanze writes: | | |> | Gabriel Dos Reis writes: | | |> | |> Fabien LE LEZ writes: | | |> | |> | On 10 Jul 2003 06:43:08 -0700, (drkm) wrote: | | |> | |> | >Cela s'approche d'une garantie, sans en être | |> | |> | >réellement une. | | |> | |> | D'un autre côté, la présence dans la norme n'est | |> | |> | pas non plus une garantie, puisqu'aucun compilo ne la suit | |> | |> | à 100 % | | |> | |> Cela est une affirmation de portée _générale_. Mais | |> | |> dans ce cas *spécifique*, peux-tu nommer une seule | |> | |> implémentation qui ne suit pas le TC1 sur ce point ? | | |> | Évidemment. Une fois n'est pas régle : on a normalisé | |> | la pratique existante. Ce qui n'enlève rien de l'affirmation | |> | générale -- la présence dans la norme n'est pas une | |> | garantie. | | |> Comme tu as pu le constater -- j'espère que tu as compris le | |> message avant d'y répondre -- je ne m'intéressais pas à | |> l'affirmation genérale. Il y a un cas concret, spécifique | |> sous les yeux, en discussion. | | Comme j'ai pu constater, tu as préféré parler à côté | plutôt que de répondre à ce que le posteur avait écrit.
Pouf, il faut que tu reactualies tes capteurs sensoriels.
| Ce | que Fabien a dit est 100% correct. Ce que tu dis aussi, mais ta | façon à le formuler en question laisse supposer que tu voulais | contradire Fabien.
Comme je l'ai rappelé dans mon message, ce que Fabien dit est une affirmation d'ordre général, dont la validité ne m'intéresse pas. Ce qui m'intéressait c'était le cas spécifique sous discussion. Mais évidemment, j'aurais dû me douter que cela te passerait complètement inaperçu.
-- Gaby
Gabriel Dos Reis
James Kanze writes:
| Gabriel Dos Reis writes: | | |> James Kanze writes: | | |> | C'est dommage, alors, qu'ils ne l'ont pas indiqué par | |> | écrit, parce qu'il n'y a absolument rien dans la norme qui en | |> | donnerait cette idée. | | |> Tout le monde est d'accord sur ce point. La syntaxe ne fait pas | |> tout. | | Il n'y a pas que du syntaxe dans la norme.
Sans aucun doute.
-- Gaby
James Kanze <kanze@alex.gabi-soft.fr> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| |> James Kanze <kanze@alex.gabi-soft.fr> writes:
|
| |> | C'est dommage, alors, qu'ils ne l'ont pas indiqué par
| |> | écrit, parce qu'il n'y a absolument rien dans la norme qui en
| |> | donnerait cette idée.
|
| |> Tout le monde est d'accord sur ce point. La syntaxe ne fait pas
| |> tout.
|
| Il n'y a pas que du syntaxe dans la norme.
| Gabriel Dos Reis writes: | | |> James Kanze writes: | | |> | C'est dommage, alors, qu'ils ne l'ont pas indiqué par | |> | écrit, parce qu'il n'y a absolument rien dans la norme qui en | |> | donnerait cette idée. | | |> Tout le monde est d'accord sur ce point. La syntaxe ne fait pas | |> tout. | | Il n'y a pas que du syntaxe dans la norme.
