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 ?
| > (et programmer en supposant cette propriété | > serait alors aventureux) | | Si elle n'est pas garantie, certainement. Bien que AMHA on peux | supposer que cela fait partie de la pratique existante et qu'aucune | implémentation ne voudrait modifier ce fait. A fortiori si un DR a | été accepté.
non seulement le DR a été accpeté, mais il fait partie du TC1, ce qui veut dire que C++2003 donne cette garantie.
-- Gaby
darkman_spam@yahoo.fr (drkm) writes:
| > (et programmer en supposant cette propriété
| > serait alors aventureux)
|
| Si elle n'est pas garantie, certainement. Bien que AMHA on peux
| supposer que cela fait partie de la pratique existante et qu'aucune
| implémentation ne voudrait modifier ce fait. A fortiori si un DR a
| été accepté.
non seulement le DR a été accpeté, mais il fait partie du TC1, ce qui
veut dire que C++2003 donne cette garantie.
| > (et programmer en supposant cette propriété | > serait alors aventureux) | | Si elle n'est pas garantie, certainement. Bien que AMHA on peux | supposer que cela fait partie de la pratique existante et qu'aucune | implémentation ne voudrait modifier ce fait. A fortiori si un DR a | été accepté.
non seulement le DR a été accpeté, mais il fait partie du TC1, ce qui veut dire que C++2003 donne cette garantie.
-- Gaby
Gabriel Dos Reis
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 ?
Dans le LWG, la réponse a été non, mais probablement que le groupe bibliothèque était ignorante.
-- Gaby
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 ?
Dans le LWG, la réponse a été non, mais probablement que le groupe
bibliothèque était ignorante.
| 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 ?
Dans le LWG, la réponse a été non, mais probablement que le groupe bibliothèque était ignorante.
-- Gaby
Gabriel Dos Reis
drkm writes:
| (drkm) writes: | | > "Alain Naigeon" wrote in message | > news:<3f0d2ae3$0$5248$... | | > > "Michel Michaud" a écrit dans le message news: | > > G54Pa.15449$ | | | > > > > En as-tu la référence, stp ? | | > > > 69 | | > Merci. | | Tiens, je vois que la date en est le 29 juillet 1998, alors que la | date d'édition de la norme est le 1er septembre de la même année. | Quand est-ce que la norme a été arrêtée, et que de telles | modifications ont dû être posposées ? | | À moins qu'il ne s'agisse tout simplement du temps pour que l'issue | soit acceptée.
Tous les cinq ans les status des normes ISO sont revisés. Dans le cas de C++, le comité a suggéré -- et les pays membres ont voté oui en majorité -- que C++ soit maintenu et que le TC1 soit incorporé à C++98 pour donner C++2003.
-- Gaby
drkm <darkman_spam@yahoo.fr> writes:
| darkman_spam@yahoo.fr (drkm) writes:
|
| > "Alain Naigeon" <anaigeon@free.fr> wrote in message
| > news:<3f0d2ae3$0$5248$626a54ce@news.free.fr>...
|
| > > "Michel Michaud" <mm@gdzid.com> a écrit dans le message news:
| > > G54Pa.15449$Tx.711385@news20.bellglobal.com...
|
|
| > > > > En as-tu la référence, stp ?
|
| > > > 69
|
| > Merci.
|
| Tiens, je vois que la date en est le 29 juillet 1998, alors que la
| date d'édition de la norme est le 1er septembre de la même année.
| Quand est-ce que la norme a été arrêtée, et que de telles
| modifications ont dû être posposées ?
|
| À moins qu'il ne s'agisse tout simplement du temps pour que l'issue
| soit acceptée.
Tous les cinq ans les status des normes ISO sont revisés. Dans le cas
de C++, le comité a suggéré -- et les pays membres ont voté oui en
majorité -- que C++ soit maintenu et que le TC1 soit incorporé à
C++98 pour donner C++2003.
| (drkm) writes: | | > "Alain Naigeon" wrote in message | > news:<3f0d2ae3$0$5248$... | | > > "Michel Michaud" a écrit dans le message news: | > > G54Pa.15449$ | | | > > > > En as-tu la référence, stp ? | | > > > 69 | | > Merci. | | Tiens, je vois que la date en est le 29 juillet 1998, alors que la | date d'édition de la norme est le 1er septembre de la même année. | Quand est-ce que la norme a été arrêtée, et que de telles | modifications ont dû être posposées ? | | À moins qu'il ne s'agisse tout simplement du temps pour que l'issue | soit acceptée.
Tous les cinq ans les status des normes ISO sont revisés. Dans le cas de C++, le comité a suggéré -- et les pays membres ont voté oui en majorité -- que C++ soit maintenu et que le TC1 soit incorporé à C++98 pour donner C++2003.
-- Gaby
Gabriel Dos Reis
"Michel Michaud" writes:
| 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 !
Ce que je prends pour une diffamation est la phrase
« et on a inventé que c'était l'intention »
et une insulte gratuite à l'egard de Alex Stepanov et ses collaborateurs.
Mais ce n'est pas la première fois qu'on va nous présenter sur ce groupe une diffamation ou un mensonge comme une figure de style nommée « hyperbole ». Ce qui en dit long sur la bonne foi des auteurs.
-- Gaby
"Michel Michaud" <mm@gdzid.com> writes:
| 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 !
Ce que je prends pour une diffamation est la phrase
« et on a inventé que c'était l'intention »
et une insulte gratuite à l'egard de Alex Stepanov et ses
collaborateurs.
Mais ce n'est pas la première fois qu'on va nous présenter sur ce
groupe une diffamation ou un mensonge comme une figure de style
nommée « hyperbole ». Ce qui en dit long sur la bonne foi des auteurs.
| 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 !
Ce que je prends pour une diffamation est la phrase
« et on a inventé que c'était l'intention »
et une insulte gratuite à l'egard de Alex Stepanov et ses collaborateurs.
Mais ce n'est pas la première fois qu'on va nous présenter sur ce groupe une diffamation ou un mensonge comme une figure de style nommée « hyperbole ». Ce qui en dit long sur la bonne foi des auteurs.
-- Gaby
Gabriel Dos Reis
"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.
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é.
| "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.
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é.
| "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.
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é.
-- Gaby
Alain Naigeon
"Gabriel Dos Reis" a écrit dans le message news:
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é.
-- Gaby
Question naïve : que faire de la notion d'adresse dans une librairie un peu abstraite ? Je m'explique :
- d'une part, tu nous dis clairement qu'on peut compter sur cette contiguïté ; - d'autre part, il me semble que la seule façon de l'utiliser serait en quelque sorte "malpropre", c'est à dire par des calculs sur pointeurs avec des sizeof, etc - autrement dit en "court-circuitant" l'interface de std::vector puisque, sauf erreur de ma part (c'est ma question) cette propriété de contiguïté n'est pas modélisée (représentée) dans cette interface ?!
N'est -ce pas un peu choquant d'avoir une propriété dont la garantie d'existence n'est pas représentée dans l'interface de la classe - c'est une entorse à l'abstraction du type !?
D'un autre côté je me demande moi-même comment représenter une telle propriété... après tout, cela concerne en premier lieu *l'implémentation* d'un itérateur sur cette classe, mais à partir du moment où l'utilisateur peut avoir accès au "prochain" élément, en quoi cela l'intéresse-t-il de savoir où il se trouve par rapport au précédent ?
Finalement j'arrive à formuler ma question sous sa forme la plus intéressante : en quoi cette contiguïté est-elle pertinente dans le contexte d'une classe munie d'un itérateur ? (dont l'usager, je me répète, n'a pas à savoir *comment* il itère).
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message
news: m3znjjhoy6.fsf@uniton.integrable-solutions.net...
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é.
-- Gaby
Question naïve : que faire de la notion d'adresse dans une
librairie un peu abstraite ? Je m'explique :
- d'une part, tu nous dis clairement qu'on peut compter
sur cette contiguïté ;
- d'autre part, il me semble que la seule façon de l'utiliser
serait en quelque sorte "malpropre", c'est à dire par des
calculs sur pointeurs avec des sizeof, etc - autrement dit
en "court-circuitant" l'interface de std::vector puisque,
sauf erreur de ma part (c'est ma question) cette propriété
de contiguïté n'est pas modélisée (représentée) dans cette
interface ?!
N'est -ce pas un peu choquant d'avoir une propriété dont
la garantie d'existence n'est pas représentée dans l'interface
de la classe - c'est une entorse à l'abstraction du type !?
D'un autre côté je me demande moi-même comment
représenter une telle propriété... après tout, cela concerne
en premier lieu *l'implémentation* d'un itérateur sur cette
classe, mais à partir du moment où l'utilisateur peut avoir
accès au "prochain" élément, en quoi cela l'intéresse-t-il
de savoir où il se trouve par rapport au précédent ?
Finalement j'arrive à formuler ma question sous sa forme la
plus intéressante : en quoi cette contiguïté est-elle pertinente
dans le contexte d'une classe munie d'un itérateur ? (dont
l'usager, je me répète, n'a pas à savoir *comment* il itère).
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
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é.
-- Gaby
Question naïve : que faire de la notion d'adresse dans une librairie un peu abstraite ? Je m'explique :
- d'une part, tu nous dis clairement qu'on peut compter sur cette contiguïté ; - d'autre part, il me semble que la seule façon de l'utiliser serait en quelque sorte "malpropre", c'est à dire par des calculs sur pointeurs avec des sizeof, etc - autrement dit en "court-circuitant" l'interface de std::vector puisque, sauf erreur de ma part (c'est ma question) cette propriété de contiguïté n'est pas modélisée (représentée) dans cette interface ?!
N'est -ce pas un peu choquant d'avoir une propriété dont la garantie d'existence n'est pas représentée dans l'interface de la classe - c'est une entorse à l'abstraction du type !?
D'un autre côté je me demande moi-même comment représenter une telle propriété... après tout, cela concerne en premier lieu *l'implémentation* d'un itérateur sur cette classe, mais à partir du moment où l'utilisateur peut avoir accès au "prochain" élément, en quoi cela l'intéresse-t-il de savoir où il se trouve par rapport au précédent ?
Finalement j'arrive à formuler ma question sous sa forme la plus intéressante : en quoi cette contiguïté est-elle pertinente dans le contexte d'une classe munie d'un itérateur ? (dont l'usager, je me répète, n'a pas à savoir *comment* il itère).
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
Gabriel Dos Reis
"Alain Naigeon" writes:
| "Gabriel Dos Reis" a écrit dans le message | news: | | > | > 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é. | > | > -- Gaby | | Question naïve : que faire de la notion d'adresse dans une | librairie un peu abstraite ? Je m'explique :
la notion d'adresse est aussi abstraite. Où est le problème ?
| - d'une part, tu nous dis clairement qu'on peut compter | sur cette contiguïté ;
Sans aucun doute.
| - d'autre part, il me semble que la seule façon de l'utiliser | serait en quelque sorte "malpropre", c'est à dire par des | calculs sur pointeurs avec des sizeof, etc - autrement dit
peux-tu expliquer cette utilisation de sizeof et en quoi ce serait « malpropre » ?
| en "court-circuitant" l'interface de std::vector puisque, | sauf erreur de ma part (c'est ma question) cette propriété | de contiguïté n'est pas modélisée (représentée) dans cette | interface ?!
C'est de la sémantique. Et il y a beaucoup de sémantique qui ne sont pas exprimée par de la syntaxe.
| N'est -ce pas un peu choquant d'avoir une propriété dont | la garantie d'existence n'est pas représentée dans l'interface | de la classe - c'est une entorse à l'abstraction du type !?
Non.
Tout simplement, parce que tout ne se réduit pas à la syntaxe.
| D'un autre côté je me demande moi-même comment | représenter une telle propriété... après tout, cela concerne
C'est une garantie *sémantique*. Si i, j sont des entiers dans les bornes alors
&v[i] == &v[j] + (i - j);
où « & » est addressof natif.
| en premier lieu *l'implémentation* d'un itérateur sur cette | classe, mais à partir du moment où l'utilisateur peut avoir | accès au "prochain" élément, en quoi cela l'intéresse-t-il | de savoir où il se trouve par rapport au précédent ?
Parce que le monde ne tourne pas autour des itérateurs ?
| Finalement j'arrive à formuler ma question sous sa forme la | plus intéressante : en quoi cette contiguïté est-elle pertinente | dans le contexte d'une classe munie d'un itérateur ? (dont | l'usager, je me répète, n'a pas à savoir *comment* il itère).
Voir ci-dessus par exemple. Mais je suis certain que si tu regardes d'autres codes avec des interfaces "C", tu verras l'utilité.
-- Gaby
"Alain Naigeon" <anaigeon@free.fr> writes:
| "Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message
| news: m3znjjhoy6.fsf@uniton.integrable-solutions.net...
|
| >
| > 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é.
| >
| > -- Gaby
|
| Question naïve : que faire de la notion d'adresse dans une
| librairie un peu abstraite ? Je m'explique :
la notion d'adresse est aussi abstraite. Où est le problème ?
| - d'une part, tu nous dis clairement qu'on peut compter
| sur cette contiguïté ;
Sans aucun doute.
| - d'autre part, il me semble que la seule façon de l'utiliser
| serait en quelque sorte "malpropre", c'est à dire par des
| calculs sur pointeurs avec des sizeof, etc - autrement dit
peux-tu expliquer cette utilisation de sizeof et en quoi ce serait
« malpropre » ?
| en "court-circuitant" l'interface de std::vector puisque,
| sauf erreur de ma part (c'est ma question) cette propriété
| de contiguïté n'est pas modélisée (représentée) dans cette
| interface ?!
C'est de la sémantique. Et il y a beaucoup de sémantique qui ne sont
pas exprimée par de la syntaxe.
| N'est -ce pas un peu choquant d'avoir une propriété dont
| la garantie d'existence n'est pas représentée dans l'interface
| de la classe - c'est une entorse à l'abstraction du type !?
Non.
Tout simplement, parce que tout ne se réduit pas à la syntaxe.
| D'un autre côté je me demande moi-même comment
| représenter une telle propriété... après tout, cela concerne
C'est une garantie *sémantique*. Si i, j sont des entiers dans les
bornes alors
&v[i] == &v[j] + (i - j);
où « & » est addressof natif.
| en premier lieu *l'implémentation* d'un itérateur sur cette
| classe, mais à partir du moment où l'utilisateur peut avoir
| accès au "prochain" élément, en quoi cela l'intéresse-t-il
| de savoir où il se trouve par rapport au précédent ?
Parce que le monde ne tourne pas autour des itérateurs ?
| Finalement j'arrive à formuler ma question sous sa forme la
| plus intéressante : en quoi cette contiguïté est-elle pertinente
| dans le contexte d'une classe munie d'un itérateur ? (dont
| l'usager, je me répète, n'a pas à savoir *comment* il itère).
Voir ci-dessus par exemple. Mais je suis certain que si tu regardes
d'autres codes avec des interfaces "C", tu verras l'utilité.
| "Gabriel Dos Reis" a écrit dans le message | news: | | > | > 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é. | > | > -- Gaby | | Question naïve : que faire de la notion d'adresse dans une | librairie un peu abstraite ? Je m'explique :
la notion d'adresse est aussi abstraite. Où est le problème ?
| - d'une part, tu nous dis clairement qu'on peut compter | sur cette contiguïté ;
Sans aucun doute.
| - d'autre part, il me semble que la seule façon de l'utiliser | serait en quelque sorte "malpropre", c'est à dire par des | calculs sur pointeurs avec des sizeof, etc - autrement dit
peux-tu expliquer cette utilisation de sizeof et en quoi ce serait « malpropre » ?
| en "court-circuitant" l'interface de std::vector puisque, | sauf erreur de ma part (c'est ma question) cette propriété | de contiguïté n'est pas modélisée (représentée) dans cette | interface ?!
C'est de la sémantique. Et il y a beaucoup de sémantique qui ne sont pas exprimée par de la syntaxe.
| N'est -ce pas un peu choquant d'avoir une propriété dont | la garantie d'existence n'est pas représentée dans l'interface | de la classe - c'est une entorse à l'abstraction du type !?
Non.
Tout simplement, parce que tout ne se réduit pas à la syntaxe.
| D'un autre côté je me demande moi-même comment | représenter une telle propriété... après tout, cela concerne
C'est une garantie *sémantique*. Si i, j sont des entiers dans les bornes alors
&v[i] == &v[j] + (i - j);
où « & » est addressof natif.
| en premier lieu *l'implémentation* d'un itérateur sur cette | classe, mais à partir du moment où l'utilisateur peut avoir | accès au "prochain" élément, en quoi cela l'intéresse-t-il | de savoir où il se trouve par rapport au précédent ?
Parce que le monde ne tourne pas autour des itérateurs ?
| Finalement j'arrive à formuler ma question sous sa forme la | plus intéressante : en quoi cette contiguïté est-elle pertinente | dans le contexte d'une classe munie d'un itérateur ? (dont | l'usager, je me répète, n'a pas à savoir *comment* il itère).
Voir ci-dessus par exemple. Mais je suis certain que si tu regardes d'autres codes avec des interfaces "C", tu verras l'utilité.
-- Gaby
James Kanze
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.
-- 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:
|> | >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.
--
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.
-- 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:
|> "Michel Michaud" writes: |> | 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 !
|> Ce que je prends pour une diffamation est la phrase
|> « et on a inventé que c'était l'intention »
|> et une insulte gratuite à l'egard de Alex Stepanov et ses |> collaborateurs.
Tu peux le prendre comme tu veux. Personellement, je ne trouve rien d'insultant à dire qu'ils ont trouvé des moyens pragmatiques pour faire passer ce qui était la pratique courante et ce que tout le monde voulait.
Mais enfin, je vis sur cette planète, et non dans un monde imaginaire où tout le monde a les mêmes intérêts que moi.
-- 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:
|> "Michel Michaud" <mm@gdzid.com> writes:
|> | 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 !
|> Ce que je prends pour une diffamation est la phrase
|> « et on a inventé que c'était l'intention »
|> et une insulte gratuite à l'egard de Alex Stepanov et ses
|> collaborateurs.
Tu peux le prendre comme tu veux. Personellement, je ne trouve rien
d'insultant à dire qu'ils ont trouvé des moyens pragmatiques
pour faire passer ce qui était la pratique courante et ce que tout
le monde voulait.
Mais enfin, je vis sur cette planète, et non dans un monde
imaginaire où tout le monde a les mêmes intérêts que moi.
--
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
|> | > "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 !
|> Ce que je prends pour une diffamation est la phrase
|> « et on a inventé que c'était l'intention »
|> et une insulte gratuite à l'egard de Alex Stepanov et ses |> collaborateurs.
Tu peux le prendre comme tu veux. Personellement, je ne trouve rien d'insultant à dire qu'ils ont trouvé des moyens pragmatiques pour faire passer ce qui était la pratique courante et ce que tout le monde voulait.
Mais enfin, je vis sur cette planète, et non dans un monde imaginaire où tout le monde a les mêmes intérêts que moi.
-- 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:
|> "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.
|> 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.
-- 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:
|> | "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.
|> 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.
--
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
|> | "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.
|> 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.
-- 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
