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 ?
Je ne sais pas à quel point c'est maintenant officiellement le cas, mais je crois qu'on peut supposer que les vector sont contigus.
Est-ce qu'il y a quoi que ce soit dans l'interface de std::vector qui suppose cette contigüité ? Si oui, la question a sa réponse. Si non, elle est sans objet. (et programmer en supposant cette propriété serait alors aventureux)
Juste mon grain de sel...
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Michel Michaud" <mm@gdzid.com> a écrit dans le message news:
G54Pa.15449$Tx.711385@news20.bellglobal.com...
Dans news:wkd6gjpah1.fsf@yahoo.fr, drkm <darkman_spam@yahoo.fr>
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
En fait, on peut dire oui, car c'était l'esprit de la chose. Il
semble que c'est ce qu'on pensait avoir dit dans la norme...
correction à la norme, je suppose que tu parlais d'un DR. En as-tu
la référence, stp ?
Je ne sais pas à quel point c'est maintenant officiellement le cas,
mais je crois qu'on peut supposer que les vector sont contigus.
Est-ce qu'il y a quoi que ce soit dans l'interface de std::vector
qui suppose cette contigüité ?
Si oui, la question a sa réponse.
Si non, elle est sans objet.
(et programmer en supposant cette propriété
serait alors aventureux)
Juste mon grain de sel...
--
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
Je ne sais pas à quel point c'est maintenant officiellement le cas, mais je crois qu'on peut supposer que les vector sont contigus.
Est-ce qu'il y a quoi que ce soit dans l'interface de std::vector qui suppose cette contigüité ? Si oui, la question a sa réponse. Si non, elle est sans objet. (et programmer en supposant cette propriété serait alors aventureux)
Juste mon grain de sel...
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
darkman_spam
"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.
Je ne sais pas à quel point c'est maintenant officiellement le cas, mais je crois qu'on peut supposer que les vector sont contigus.
Est-ce qu'il y a quoi que ce soit dans l'interface de std::vector qui suppose cette contigüité ? Si oui, la question a sa réponse. Si non, elle est sans objet.
L'opérateur `std::vector< T >::operator[]()´ ne suppose en rien cette contigüité. Néanmoins, le code suivant démontre que cette question est loin d'être sans objet :
Si je me souvient bien, l'article original portait sur l'utilisation de vector avec les fonctions POSIX `read()´ et `write()´, qui prennent un buffer (resp. en lecture et en écriture, pour les IO fichiers).
(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é. Cela s'approche d'une garantie, sans en être réellement une.
--drkm
"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.
Je ne sais pas à quel point c'est maintenant officiellement le
cas, mais je crois qu'on peut supposer que les vector sont
contigus.
Est-ce qu'il y a quoi que ce soit dans l'interface de std::vector
qui suppose cette contigüité ?
Si oui, la question a sa réponse.
Si non, elle est sans objet.
L'opérateur `std::vector< T >::operator[]()´ ne suppose en rien
cette contigüité. Néanmoins, le code suivant démontre que cette
question est loin d'être sans objet :
Si je me souvient bien, l'article original portait sur l'utilisation
de vector avec les fonctions POSIX `read()´ et `write()´, qui prennent
un buffer (resp. en lecture et en écriture, pour les IO fichiers).
(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é. Cela s'approche d'une garantie, sans en être réellement
une.
"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.
Je ne sais pas à quel point c'est maintenant officiellement le cas, mais je crois qu'on peut supposer que les vector sont contigus.
Est-ce qu'il y a quoi que ce soit dans l'interface de std::vector qui suppose cette contigüité ? Si oui, la question a sa réponse. Si non, elle est sans objet.
L'opérateur `std::vector< T >::operator[]()´ ne suppose en rien cette contigüité. Néanmoins, le code suivant démontre que cette question est loin d'être sans objet :
Si je me souvient bien, l'article original portait sur l'utilisation de vector avec les fonctions POSIX `read()´ et `write()´, qui prennent un buffer (resp. en lecture et en écriture, pour les IO fichiers).
(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é. Cela s'approche d'une garantie, sans en être réellement une.
--drkm
kanze
"Alain Naigeon" wrote in message news:<3f0d2ae3$0$5248$...
"Michel Michaud" a écrit dans le message news: G54Pa.15449$
Dans news:, drkm
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
En fait, on peut dire oui, car c'était l'esprit de la chose. Il semble que c'est ce qu'on pensait avoir dit dans la norme...
correction à la norme, je suppose que tu parlais d'un DR. En as-tu la référence, stp ?
Je ne sais pas à quel point c'est maintenant officiellement le cas, mais je crois qu'on peut supposer que les vector sont contigus.
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 qu'on a oublié de le préciser, tellement ça paraissait évident. C'est donc maintenant une exigeance. (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.)
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"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...
Dans news:wkd6gjpah1.fsf@yahoo.fr, drkm <darkman_spam@yahoo.fr>
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
En fait, on peut dire oui, car c'était l'esprit de la chose. Il
semble que c'est ce qu'on pensait avoir dit dans la norme...
correction à la norme, je suppose que tu parlais d'un DR. En
as-tu la référence, stp ?
Je ne sais pas à quel point c'est maintenant officiellement le cas,
mais je crois qu'on peut supposer que les vector sont contigus.
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 qu'on a oublié de le
préciser, tellement ça paraissait évident. C'est donc maintenant une
exigeance. (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.)
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Je ne sais pas à quel point c'est maintenant officiellement le cas, mais je crois qu'on peut supposer que les vector sont contigus.
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 qu'on a oublié de le préciser, tellement ça paraissait évident. C'est donc maintenant une exigeance. (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.)
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Fabien LE LEZ
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 % (y'a qu'à voir export, ou même les iostream -- tu auras vraisemblablement plus de problèmes de portabilité en supposant que tous les compilateurs implémentent correctement les iostreams qu'en supposant que pour tous les compilateurs, les éléments d'un vector sont contigus).
-- Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/ et http://www.aminautes.org/forums/serveurs/tablefr.html Archives : http://groups.google.com/advanced_group_search http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
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 % (y'a qu'à voir
export, ou même les iostream -- tu auras vraisemblablement plus de
problèmes de portabilité en supposant que tous les compilateurs
implémentent correctement les iostreams qu'en supposant que pour tous
les compilateurs, les éléments d'un vector sont contigus).
--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
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 % (y'a qu'à voir export, ou même les iostream -- tu auras vraisemblablement plus de problèmes de portabilité en supposant que tous les compilateurs implémentent correctement les iostreams qu'en supposant que pour tous les compilateurs, les éléments d'un vector sont contigus).
-- Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/ et http://www.aminautes.org/forums/serveurs/tablefr.html Archives : http://groups.google.com/advanced_group_search http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
Michel Michaud
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 ?
qu'on a oublié de le préciser, tellement ça paraissait évident. C'est donc maintenant une exigeance. (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.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
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 ?
qu'on a oublié de le préciser, tellement ça paraissait évident.
C'est donc maintenant une exigeance. (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.
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
"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 ?
qu'on a oublié de le préciser, tellement ça paraissait évident. C'est donc maintenant une exigeance. (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.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Christophe Lephay
"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.
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.
Chris
"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.
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.
"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.
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.
Chris
Michel Michaud
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[]... Dans ce cas (comme dans string::data()), on pense à la compatibilité, pas à des questions de choix de structures de données. Je veux un vecteur dynamique et j'aimerais pouvoir une compatibilité avec les tableaux à la C...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
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[]... Dans ce cas (comme dans string::data()), on
pense à la compatibilité, pas à des questions de choix de
structures de données. Je veux un vecteur dynamique et j'aimerais
pouvoir une compatibilité avec les tableaux à la C...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
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[]... Dans ce cas (comme dans string::data()), on pense à la compatibilité, pas à des questions de choix de structures de données. Je veux un vecteur dynamique et j'aimerais pouvoir une compatibilité avec les tableaux à la C...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
kanze
"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 ? Ce n'est pas une accusation, mais une constatation. Le comité est un organisme politique. Il ne peut pas en être autrement ; il s'agit de créer un consensus entre des gens des horizons très variés.
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 pas pris en compte. Et qui marchait bien avec toutes les implémentations existantes. Or, formellement, on n'est censé à ne rien ajouter de neuf après la publication -- mais on peut clarifier ou corriger. Alors, on a décidé que c'était ce qu'on avait voulu, mais qu'on a oublié à dire, pour que le changement passe dans les régles.
Moi, je suis tout à fait d'accord avec la procédure. Techniquement, peut-être, on a triché, mais la norme en est mieux pour autant.
qu'on a oublié de le préciser, tellement ça paraissait évident. C'est donc maintenant une exigeance. (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.
Disons qu'une fonction data() serait plus claire.
En fait, la meilleur solution (c-à-d la plus conforme à ce qui fait ailleurs dans la norme) n'aurait pas été d'exiger la contiguïté dans l'implémentation, mais de spécifier une fonction data(), qui renvoyer un pointeur à des éléments contigus, et puis exiger qu'il ait une complexité constante, et qu'il n'appelle ni le constructeur de copie ni l'opérateur d'affectation. Mais ç'aurait été plus difficile à faire avaler qu'on a oublié une fonction complète, dont on avait l'intention... Et la solution actuelle est tout à fait acceptable.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"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 ? Ce n'est pas une accusation, mais une constatation. Le
comité est un organisme politique. Il ne peut pas en être autrement ; il
s'agit de créer un consensus entre des gens des horizons très variés.
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
pas pris en compte. Et qui marchait bien avec toutes les implémentations
existantes. Or, formellement, on n'est censé à ne rien ajouter de neuf
après la publication -- mais on peut clarifier ou corriger. Alors, on a
décidé que c'était ce qu'on avait voulu, mais qu'on a oublié à dire,
pour que le changement passe dans les régles.
Moi, je suis tout à fait d'accord avec la procédure. Techniquement,
peut-être, on a triché, mais la norme en est mieux pour autant.
qu'on a oublié de le préciser, tellement ça paraissait évident.
C'est donc maintenant une exigeance. (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.
Disons qu'une fonction data() serait plus claire.
En fait, la meilleur solution (c-à-d la plus conforme à ce qui fait
ailleurs dans la norme) n'aurait pas été d'exiger la contiguïté dans
l'implémentation, mais de spécifier une fonction data(), qui renvoyer un
pointeur à des éléments contigus, et puis exiger qu'il ait une
complexité constante, et qu'il n'appelle ni le constructeur de copie ni
l'opérateur d'affectation. Mais ç'aurait été plus difficile à faire
avaler qu'on a oublié une fonction complète, dont on avait
l'intention... Et la solution actuelle est tout à fait acceptable.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"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 ? Ce n'est pas une accusation, mais une constatation. Le comité est un organisme politique. Il ne peut pas en être autrement ; il s'agit de créer un consensus entre des gens des horizons très variés.
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 pas pris en compte. Et qui marchait bien avec toutes les implémentations existantes. Or, formellement, on n'est censé à ne rien ajouter de neuf après la publication -- mais on peut clarifier ou corriger. Alors, on a décidé que c'était ce qu'on avait voulu, mais qu'on a oublié à dire, pour que le changement passe dans les régles.
Moi, je suis tout à fait d'accord avec la procédure. Techniquement, peut-être, on a triché, mais la norme en est mieux pour autant.
qu'on a oublié de le préciser, tellement ça paraissait évident. C'est donc maintenant une exigeance. (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.
Disons qu'une fonction data() serait plus claire.
En fait, la meilleur solution (c-à-d la plus conforme à ce qui fait ailleurs dans la norme) n'aurait pas été d'exiger la contiguïté dans l'implémentation, mais de spécifier une fonction data(), qui renvoyer un pointeur à des éléments contigus, et puis exiger qu'il ait une complexité constante, et qu'il n'appelle ni le constructeur de copie ni l'opérateur d'affectation. Mais ç'aurait été plus difficile à faire avaler qu'on a oublié une fonction complète, dont on avait l'intention... Et la solution actuelle est tout à fait acceptable.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
drkm
(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.
--drkm
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.
"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.
