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 ?
| Jean-Marc Bourguet wrote: | | >>>Tu sais comment marche auto_ptr ? | >>Je crois, oui. | > Tu peux m'expliquer comment ca ce fait qu'on peut retourner un | > auto_ptr comme resultat d'une fonction? | | Parce que son constructeur par copie transfert la propriété ?
| Jean-Marc Bourguet wrote:
|
| >>>Tu sais comment marche auto_ptr ?
| >>Je crois, oui.
| > Tu peux m'expliquer comment ca ce fait qu'on peut retourner un
| > auto_ptr comme resultat d'une fonction?
|
| Parce que son constructeur par copie transfert la propriété ?
| Jean-Marc Bourguet wrote: | | >>>Tu sais comment marche auto_ptr ? | >>Je crois, oui. | > Tu peux m'expliquer comment ca ce fait qu'on peut retourner un | > auto_ptr comme resultat d'une fonction? | | Parce que son constructeur par copie transfert la propriété ?
Mais encore ?
-- Gaby
Arnaud Meurgues
Jean-Marc Bourguet wrote:
Le fait de passer un indice de ligne ou un indice de colonne est attendu est une erreur de typage en Pascal (ou en Ada) bien programme.
Ok. Merci. Je n'avais pas compris ça (je l'ai compris ensuite dans sa réponse à Gabriel).
Arnaud
Jean-Marc Bourguet wrote:
Le fait de passer un indice de ligne ou un indice de colonne est
attendu est une erreur de typage en Pascal (ou en Ada) bien programme.
Ok. Merci. Je n'avais pas compris ça (je l'ai compris ensuite dans sa
réponse à Gabriel).
| Voilà un ensemble d'énoncés qui sont des illustrations | particulièrement frappantes de ce que j'appelle « pragmatisme ».
J'appelle ça plutôt « réalisme et flexibilité ».
Pourquoi pas ? Et quelle est ta définition de « pragmatisme » ?
Arnaud
Gabriel Dos Reis
Arnaud Meurgues writes:
| Gabriel Dos Reis wrote: | | > | >>>Tu sais comment marche auto_ptr ? | > | >>Je crois, oui. | > | > Tu peux m'expliquer comment ca ce fait qu'on peut retourner un | > | > auto_ptr comme resultat d'une fonction? | > | Parce que son constructeur par copie transfert la propriété ? | > Mais encore ? | | Je ne sais pas ce que tu veux dire, ce qui semble signifier que je ne | sais pas vraiment comment marche auto_ptr, ce que je n'ai jamais nié.
Je n'ai pas dit que tu l'as nié puisque je n'ai pas avancé l'affirmation que tu ne saurais pas comment marche auto_ptr.
J'ai simplement demandé si tu savais comment ça marche. J'ai pris « je crois, oui » pour ce qu'il signifiait. Par la réponse que tu as donné à Jean-Marc, j'ai conclu que tu n'as pas dit le principal parce que dans
void f(auto_ptr<T>, auto_ptr<T>);
f(new T, new T);
l'exemple que tu as rappelé, le constructeur de copie n'est jamais utilisé. (je passe sous silence le fait que ce n'est pas bien formé, car ce n'est pas réellement important).
| Pourrais-tu me mettre sur la piste de la difficulté que je ne vois pas | afin de me laisser une chance de trouver la solution ?
| Gabriel Dos Reis wrote:
|
| > | >>>Tu sais comment marche auto_ptr ?
| > | >>Je crois, oui.
| > | > Tu peux m'expliquer comment ca ce fait qu'on peut retourner un
| > | > auto_ptr comme resultat d'une fonction?
| > | Parce que son constructeur par copie transfert la propriété ?
| > Mais encore ?
|
| Je ne sais pas ce que tu veux dire, ce qui semble signifier que je ne
| sais pas vraiment comment marche auto_ptr, ce que je n'ai jamais nié.
Je n'ai pas dit que tu l'as nié puisque je n'ai pas avancé
l'affirmation que tu ne saurais pas comment marche auto_ptr.
J'ai simplement demandé si tu savais comment ça marche. J'ai pris
« je crois, oui » pour ce qu'il signifiait. Par la réponse que tu as
donné à Jean-Marc, j'ai conclu que tu n'as pas dit le principal parce
que dans
void f(auto_ptr<T>, auto_ptr<T>);
f(new T, new T);
l'exemple que tu as rappelé, le constructeur de copie n'est jamais utilisé.
(je passe sous silence le fait que ce n'est pas bien formé, car ce
n'est pas réellement important).
| Pourrais-tu me mettre sur la piste de la difficulté que je ne vois pas
| afin de me laisser une chance de trouver la solution ?
| Gabriel Dos Reis wrote: | | > | >>>Tu sais comment marche auto_ptr ? | > | >>Je crois, oui. | > | > Tu peux m'expliquer comment ca ce fait qu'on peut retourner un | > | > auto_ptr comme resultat d'une fonction? | > | Parce que son constructeur par copie transfert la propriété ? | > Mais encore ? | | Je ne sais pas ce que tu veux dire, ce qui semble signifier que je ne | sais pas vraiment comment marche auto_ptr, ce que je n'ai jamais nié.
Je n'ai pas dit que tu l'as nié puisque je n'ai pas avancé l'affirmation que tu ne saurais pas comment marche auto_ptr.
J'ai simplement demandé si tu savais comment ça marche. J'ai pris « je crois, oui » pour ce qu'il signifiait. Par la réponse que tu as donné à Jean-Marc, j'ai conclu que tu n'as pas dit le principal parce que dans
void f(auto_ptr<T>, auto_ptr<T>);
f(new T, new T);
l'exemple que tu as rappelé, le constructeur de copie n'est jamais utilisé. (je passe sous silence le fait que ce n'est pas bien formé, car ce n'est pas réellement important).
| Pourrais-tu me mettre sur la piste de la difficulté que je ne vois pas | afin de me laisser une chance de trouver la solution ?
J'ai donné un lien sur la page de Nico Josuttis.
-- Gaby
Christophe de Vienne
Gabriel Dos Reis wrote:
Arnaud Meurgues writes:
| Jean-Marc Bourguet wrote: | | >>>Tu sais comment marche auto_ptr ? | >>Je crois, oui. | > Tu peux m'expliquer comment ca ce fait qu'on peut retourner un | > auto_ptr comme resultat d'une fonction? | | Parce que son constructeur par copie transfert la propriété ?
Mais encore ?
Si j'ai bien compris, c'est parce qu'il a une conversion vers une structure ad-hoc qui fait au passage l'équivalent d'un release, ainsi qu'un constructeur prenant cette même structure. Dans la structure en question se trouve un pointeur vers l'objet dont on transfère la propriété.
Il y a donc, au moment du return un passage par un type intermédiaire. Ce qui m'échappe un peu, c'est comment le compilateur 'trouve' ce passage.
-- Christophe de Vienne Experience is something you don't get until just after you need it. Oliver's Law.
| Jean-Marc Bourguet wrote:
|
| >>>Tu sais comment marche auto_ptr ?
| >>Je crois, oui.
| > Tu peux m'expliquer comment ca ce fait qu'on peut retourner un
| > auto_ptr comme resultat d'une fonction?
|
| Parce que son constructeur par copie transfert la propriété ?
Mais encore ?
Si j'ai bien compris, c'est parce qu'il a une conversion vers une structure
ad-hoc qui fait au passage l'équivalent d'un release, ainsi qu'un
constructeur prenant cette même structure. Dans la structure en question se
trouve un pointeur vers l'objet dont on transfère la propriété.
Il y a donc, au moment du return un passage par un type intermédiaire. Ce
qui m'échappe un peu, c'est comment le compilateur 'trouve' ce passage.
--
Christophe de Vienne
Experience is something you don't get until just after you need it.
Oliver's Law.
| Jean-Marc Bourguet wrote: | | >>>Tu sais comment marche auto_ptr ? | >>Je crois, oui. | > Tu peux m'expliquer comment ca ce fait qu'on peut retourner un | > auto_ptr comme resultat d'une fonction? | | Parce que son constructeur par copie transfert la propriété ?
Mais encore ?
Si j'ai bien compris, c'est parce qu'il a une conversion vers une structure ad-hoc qui fait au passage l'équivalent d'un release, ainsi qu'un constructeur prenant cette même structure. Dans la structure en question se trouve un pointeur vers l'objet dont on transfère la propriété.
Il y a donc, au moment du return un passage par un type intermédiaire. Ce qui m'échappe un peu, c'est comment le compilateur 'trouve' ce passage.
-- Christophe de Vienne Experience is something you don't get until just after you need it. Oliver's Law.
Gabriel Dos Reis
Christophe de Vienne writes:
| Gabriel Dos Reis wrote: | | > Arnaud Meurgues writes: | > | > | Jean-Marc Bourguet wrote: | > | | > | >>>Tu sais comment marche auto_ptr ? | > | >>Je crois, oui. | > | > Tu peux m'expliquer comment ca ce fait qu'on peut retourner un | > | > auto_ptr comme resultat d'une fonction? | > | | > | Parce que son constructeur par copie transfert la propriété ? | > | > Mais encore ? | > | | Si j'ai bien compris, c'est parce qu'il a une conversion vers une structure | ad-hoc qui fait au passage l'équivalent d'un release,
La structure initermédiaire elle-même ne fait pas ce release au moment de sa construction -- c'est au moment où elle atteint son but que le release est fait.
| ainsi qu'un | constructeur prenant cette même structure. Dans la structure en question se | trouve un pointeur vers l'objet dont on transfère la propriété.
Plus exactement, la structure intermédiaire contient une référence sur l'auto_ptr que l'on veut copier -- enfin abstraitement, c'est comme cela que c'est spécifié.
Mais je crois que tu as saisi l'essentiel : si tu initialises un auto_ptr<T> par une rvalue auto_ptr<T>, l'initialisation ne se fera pas par le constructeur de copie -- contrairement au but avoué des constructeurs de copie (et je crois que Arnaud a donné sa réponse instinctivement en pensant que cela marche pareil que pour les autres).
| Il y a donc, au moment du return un passage par un type intermédiaire. Ce | qui m'échappe un peu, c'est comment le compilateur 'trouve' ce passage.
voir l'explication donnée par Nico -- j'ai posté un lien sur sa page.
-- Gaby
Christophe de Vienne <cdevienne@alphacent.com> writes:
| Gabriel Dos Reis wrote:
|
| > Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> writes:
| >
| > | Jean-Marc Bourguet wrote:
| > |
| > | >>>Tu sais comment marche auto_ptr ?
| > | >>Je crois, oui.
| > | > Tu peux m'expliquer comment ca ce fait qu'on peut retourner un
| > | > auto_ptr comme resultat d'une fonction?
| > |
| > | Parce que son constructeur par copie transfert la propriété ?
| >
| > Mais encore ?
| >
|
| Si j'ai bien compris, c'est parce qu'il a une conversion vers une structure
| ad-hoc qui fait au passage l'équivalent d'un release,
La structure initermédiaire elle-même ne fait pas ce release au moment
de sa construction -- c'est au moment où elle atteint son but que le
release est fait.
| ainsi qu'un
| constructeur prenant cette même structure. Dans la structure en question se
| trouve un pointeur vers l'objet dont on transfère la propriété.
Plus exactement, la structure intermédiaire contient une référence sur
l'auto_ptr que l'on veut copier -- enfin abstraitement, c'est comme
cela que c'est spécifié.
Mais je crois que tu as saisi l'essentiel : si tu initialises un
auto_ptr<T> par une rvalue auto_ptr<T>, l'initialisation ne se fera
pas par le constructeur de copie -- contrairement au but avoué des
constructeurs de copie (et je crois que Arnaud a donné sa réponse
instinctivement en pensant que cela marche pareil que pour les autres).
| Il y a donc, au moment du return un passage par un type intermédiaire. Ce
| qui m'échappe un peu, c'est comment le compilateur 'trouve' ce passage.
voir l'explication donnée par Nico -- j'ai posté un lien sur sa page.
| Gabriel Dos Reis wrote: | | > Arnaud Meurgues writes: | > | > | Jean-Marc Bourguet wrote: | > | | > | >>>Tu sais comment marche auto_ptr ? | > | >>Je crois, oui. | > | > Tu peux m'expliquer comment ca ce fait qu'on peut retourner un | > | > auto_ptr comme resultat d'une fonction? | > | | > | Parce que son constructeur par copie transfert la propriété ? | > | > Mais encore ? | > | | Si j'ai bien compris, c'est parce qu'il a une conversion vers une structure | ad-hoc qui fait au passage l'équivalent d'un release,
La structure initermédiaire elle-même ne fait pas ce release au moment de sa construction -- c'est au moment où elle atteint son but que le release est fait.
| ainsi qu'un | constructeur prenant cette même structure. Dans la structure en question se | trouve un pointeur vers l'objet dont on transfère la propriété.
Plus exactement, la structure intermédiaire contient une référence sur l'auto_ptr que l'on veut copier -- enfin abstraitement, c'est comme cela que c'est spécifié.
Mais je crois que tu as saisi l'essentiel : si tu initialises un auto_ptr<T> par une rvalue auto_ptr<T>, l'initialisation ne se fera pas par le constructeur de copie -- contrairement au but avoué des constructeurs de copie (et je crois que Arnaud a donné sa réponse instinctivement en pensant que cela marche pareil que pour les autres).
| Il y a donc, au moment du return un passage par un type intermédiaire. Ce | qui m'échappe un peu, c'est comment le compilateur 'trouve' ce passage.
voir l'explication donnée par Nico -- j'ai posté un lien sur sa page.
-- Gaby
Frederic Py
Christophe de Vienne wrote:
Gabriel Dos Reis wrote:
Si j'ai bien compris, c'est parce qu'il a une conversion vers une structure ad-hoc qui fait au passage l'équivalent d'un release, ainsi qu'un constructeur prenant cette même structure. Dans la structure en question se trouve un pointeur vers l'objet dont on transfère la propriété.
Il y a donc, au moment du return un passage par un type intermédiaire. Ce qui m'échappe un peu, c'est comment le compilateur 'trouve' ce passage.
C'est le seul moyen qu'il ait de faire laopie de auto_ptr vers auto_ptr
il prends donc tout simplement les miettes qui lui sont laissees.
Lors de mes tout debuts en C++, je m'etais trouve face a des erreurs issues de ce genre de comportement du compilo associes a un mauvais codage de ma part.
Mais je n'avaias jamais pense a utilsiser ceci afin de contourner certains problemes comme cela a ete fait pour auto_ptr.
-- Frederic Py
Christophe de Vienne wrote:
Gabriel Dos Reis wrote:
Si j'ai bien compris, c'est parce qu'il a une conversion vers une structure
ad-hoc qui fait au passage l'équivalent d'un release, ainsi qu'un
constructeur prenant cette même structure. Dans la structure en question se
trouve un pointeur vers l'objet dont on transfère la propriété.
Il y a donc, au moment du return un passage par un type intermédiaire. Ce
qui m'échappe un peu, c'est comment le compilateur 'trouve' ce passage.
C'est le seul moyen qu'il ait de faire laopie de auto_ptr vers auto_ptr
il prends donc tout simplement les miettes qui lui sont laissees.
Lors de mes tout debuts en C++, je m'etais trouve face a des erreurs
issues de ce genre de comportement du compilo associes a un mauvais
codage de ma part.
Mais je n'avaias jamais pense a utilsiser ceci afin de contourner
certains problemes comme cela a ete fait pour auto_ptr.
Si j'ai bien compris, c'est parce qu'il a une conversion vers une structure ad-hoc qui fait au passage l'équivalent d'un release, ainsi qu'un constructeur prenant cette même structure. Dans la structure en question se trouve un pointeur vers l'objet dont on transfère la propriété.
Il y a donc, au moment du return un passage par un type intermédiaire. Ce qui m'échappe un peu, c'est comment le compilateur 'trouve' ce passage.
C'est le seul moyen qu'il ait de faire laopie de auto_ptr vers auto_ptr
il prends donc tout simplement les miettes qui lui sont laissees.
Lors de mes tout debuts en C++, je m'etais trouve face a des erreurs issues de ce genre de comportement du compilo associes a un mauvais codage de ma part.
Mais je n'avaias jamais pense a utilsiser ceci afin de contourner certains problemes comme cela a ete fait pour auto_ptr.
-- Frederic Py
Christophe de Vienne
Christophe de Vienne wrote:
ainsi qu'un constructeur prenant cette même structure.
Je rectifie ce point : ce n'est pas un constructeur mais un opérateur = qui est définit.
Il y a donc, au moment du return un passage par un type intermédiaire. Ce qui m'échappe un peu, c'est comment le compilateur 'trouve' ce passage.
J'imagine que l'histoire de l'opérateur joue là-dedans mais j'ai du mal à voir exactement comment.
-- Christophe de Vienne Experience is something you don't get until just after you need it. Oliver's Law.
Christophe de Vienne wrote:
ainsi
qu'un constructeur prenant cette même structure.
Je rectifie ce point : ce n'est pas un constructeur mais un opérateur = qui
est définit.
Il y a donc, au moment du return un passage par un type intermédiaire. Ce
qui m'échappe un peu, c'est comment le compilateur 'trouve' ce passage.
J'imagine que l'histoire de l'opérateur joue là-dedans mais j'ai du mal à
voir exactement comment.
--
Christophe de Vienne
Experience is something you don't get until just after you need it.
Oliver's Law.
ainsi qu'un constructeur prenant cette même structure.
Je rectifie ce point : ce n'est pas un constructeur mais un opérateur = qui est définit.
Il y a donc, au moment du return un passage par un type intermédiaire. Ce qui m'échappe un peu, c'est comment le compilateur 'trouve' ce passage.
J'imagine que l'histoire de l'opérateur joue là-dedans mais j'ai du mal à voir exactement comment.
-- Christophe de Vienne Experience is something you don't get until just after you need it. Oliver's Law.
Arnaud Meurgues
Gabriel Dos Reis wrote:
Par la réponse que tu as donné à Jean-Marc, j'ai conclu que tu n'as pas dit le principal parce que dans
void f(auto_ptr<T>, auto_ptr<T>);
f(new T, new T);
l'exemple que tu as rappelé, le constructeur de copie n'est jamais utilisé.
Effectivement. Mais le problème qui était posé par cette construction est de même nature que celui posé par le fait qu'une fonction ait auto_ptr comme type de retour ?
J'avais compris que le problème dans le cas ci-dessus venait de la possibilité que le deuxième T soit créé avant que le premier auto_ptr ait été construit. J'ai du mal à voir comment le constructeur par copie, dans ce problème, est impliqué.
J'ai donné un lien sur la page de Nico Josuttis.
J'ai vu, merci. Je comprends pourquoi tu parlais de machiavélisme. C'est curieux, il me semble me souvenir d'une implémentation de auto_ptr donnée par Scott Meyers mais d'aucune classe proxy auto_ptr_ref. C'est ma mémoire qui flanche (ce qui ne serait pas la première fois) ?
Arnaud
Gabriel Dos Reis wrote:
Par la réponse que tu as
donné à Jean-Marc, j'ai conclu que tu n'as pas dit le principal parce
que dans
void f(auto_ptr<T>, auto_ptr<T>);
f(new T, new T);
l'exemple que tu as rappelé, le constructeur de copie n'est jamais utilisé.
Effectivement. Mais le problème qui était posé par cette construction
est de même nature que celui posé par le fait qu'une fonction ait
auto_ptr comme type de retour ?
J'avais compris que le problème dans le cas ci-dessus venait de la
possibilité que le deuxième T soit créé avant que le premier auto_ptr
ait été construit. J'ai du mal à voir comment le constructeur par copie,
dans ce problème, est impliqué.
J'ai donné un lien sur la page de Nico Josuttis.
J'ai vu, merci. Je comprends pourquoi tu parlais de machiavélisme. C'est
curieux, il me semble me souvenir d'une implémentation de auto_ptr
donnée par Scott Meyers mais d'aucune classe proxy auto_ptr_ref. C'est
ma mémoire qui flanche (ce qui ne serait pas la première fois) ?
Par la réponse que tu as donné à Jean-Marc, j'ai conclu que tu n'as pas dit le principal parce que dans
void f(auto_ptr<T>, auto_ptr<T>);
f(new T, new T);
l'exemple que tu as rappelé, le constructeur de copie n'est jamais utilisé.
Effectivement. Mais le problème qui était posé par cette construction est de même nature que celui posé par le fait qu'une fonction ait auto_ptr comme type de retour ?
J'avais compris que le problème dans le cas ci-dessus venait de la possibilité que le deuxième T soit créé avant que le premier auto_ptr ait été construit. J'ai du mal à voir comment le constructeur par copie, dans ce problème, est impliqué.
J'ai donné un lien sur la page de Nico Josuttis.
J'ai vu, merci. Je comprends pourquoi tu parlais de machiavélisme. C'est curieux, il me semble me souvenir d'une implémentation de auto_ptr donnée par Scott Meyers mais d'aucune classe proxy auto_ptr_ref. C'est ma mémoire qui flanche (ce qui ne serait pas la première fois) ?
Arnaud
Christophe Lephay
"Gabriel Dos Reis" a écrit dans le message de news:
"Christophe Lephay" writes:
| Dans le deuxième cas, quand on voit avec quel soin (pointillisme ?) chaque
| mot est discuté pendant de nombreuses heures par le comité (à ce qu'il | semble), on voit mal comment celà aurait pu passer à travers et être oublié.
alors pourquoi le comité a-t-il mis enplace le processus de DR ?
Quel rapport ? La question (assez peu interessante d'un point de vue concret, du reste) est si l'intention du comité était de faire de la contiguité des éléments de vector quelque chose d'obligatoire ou de le considérer comme quelque chose relevant de l'implémentation, pourvu que soit fourni un moyen d'assurer la compatibilité avec le C.
| Je trouve le premier cas plus crédible,
Je trouve surtout que ces deux catégorisations reflètent une ignorance profonde du processus de normalisation, en tout cas dans WG21.
Bien que je trouve ta remarque un peu sentencieuse (comme si le fait que tu trouves ceci ou celà était suffisant en soi et ne nécessitait pas que tu argumentes), je t'accorde d'autant plus le fait que que je n'y connaisse effectivement pas grand chose que j n'y suis pas particulièrement interessé (ce qui ne veut pas dire que je n'y sois particulièrement pas interessé)...
Chris
"Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message de
news:m3he5l1lbz.fsf@uniton.integrable-solutions.net...
| Dans le deuxième cas, quand on voit avec quel soin (pointillisme ?)
chaque
| mot est discuté pendant de nombreuses heures par le comité (à ce qu'il
| semble), on voit mal comment celà aurait pu passer à travers et être
oublié.
alors pourquoi le comité a-t-il mis enplace le processus de DR ?
Quel rapport ? La question (assez peu interessante d'un point de vue
concret, du reste) est si l'intention du comité était de faire de la
contiguité des éléments de vector quelque chose d'obligatoire ou de le
considérer comme quelque chose relevant de l'implémentation, pourvu que soit
fourni un moyen d'assurer la compatibilité avec le C.
| Je trouve le premier cas plus crédible,
Je trouve surtout que ces deux catégorisations reflètent une ignorance
profonde du processus de normalisation, en tout cas dans WG21.
Bien que je trouve ta remarque un peu sentencieuse (comme si le fait que tu
trouves ceci ou celà était suffisant en soi et ne nécessitait pas que tu
argumentes), je t'accorde d'autant plus le fait que que je n'y connaisse
effectivement pas grand chose que j n'y suis pas particulièrement interessé
(ce qui ne veut pas dire que je n'y sois particulièrement pas interessé)...
"Gabriel Dos Reis" a écrit dans le message de news:
"Christophe Lephay" writes:
| Dans le deuxième cas, quand on voit avec quel soin (pointillisme ?) chaque
| mot est discuté pendant de nombreuses heures par le comité (à ce qu'il | semble), on voit mal comment celà aurait pu passer à travers et être oublié.
alors pourquoi le comité a-t-il mis enplace le processus de DR ?
Quel rapport ? La question (assez peu interessante d'un point de vue concret, du reste) est si l'intention du comité était de faire de la contiguité des éléments de vector quelque chose d'obligatoire ou de le considérer comme quelque chose relevant de l'implémentation, pourvu que soit fourni un moyen d'assurer la compatibilité avec le C.
| Je trouve le premier cas plus crédible,
Je trouve surtout que ces deux catégorisations reflètent une ignorance profonde du processus de normalisation, en tout cas dans WG21.
Bien que je trouve ta remarque un peu sentencieuse (comme si le fait que tu trouves ceci ou celà était suffisant en soi et ne nécessitait pas que tu argumentes), je t'accorde d'autant plus le fait que que je n'y connaisse effectivement pas grand chose que j n'y suis pas particulièrement interessé (ce qui ne veut pas dire que je n'y sois particulièrement pas interessé)...
