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 ?
| 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.
Je serais tenté de dire que c'est une bonne chose que le compilateur ait râlé et que tu ne connaissais pas à l'époque ce qui fait marcher auto_ptr.
-- Gaby
Frederic Py <fpy.sospam@laas.rf> writes:
| 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.
Je serais tenté de dire que c'est une bonne chose que le compilateur
ait râlé et que tu ne connaissais pas à l'époque ce qui fait marcher
auto_ptr.
| 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.
Je serais tenté de dire que c'est une bonne chose que le compilateur ait râlé et que tu ne connaissais pas à l'époque ce qui fait marcher auto_ptr.
-- Gaby
Jean-Marc Bourguet
Arnaud Meurgues writes:
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) ?
La page de Josuttis a un lien vers la page de Meyers sur le sujet. auto_ptr a change pas mal.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
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) ?
La page de Josuttis a un lien vers la page de Meyers sur le sujet.
auto_ptr a change pas mal.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
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) ?
La page de Josuttis a un lien vers la page de Meyers sur le sujet. auto_ptr a change pas mal.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Frederic Py
Gabriel Dos Reis wrote:
Frederic Py writes:
| 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.
Je serais tenté de dire que c'est une bonne chose que le compilateur ait râlé et que tu ne connaissais pas à l'époque ce qui fait marcher auto_ptr.
Je serais tente d'etre d'accord avec toi et d'ailleur meme si je me coucherais moins bete ce soir ce hack ne sera pas a mon avis utilise avant longtemps par ma personne :)
-- Frederic Py
Gabriel Dos Reis wrote:
Frederic Py <fpy.sospam@laas.rf> writes:
| 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.
Je serais tenté de dire que c'est une bonne chose que le compilateur
ait râlé et que tu ne connaissais pas à l'époque ce qui fait marcher
auto_ptr.
Je serais tente d'etre d'accord avec toi et d'ailleur meme si je me
coucherais moins bete ce soir ce hack ne sera pas a mon avis utilise
avant longtemps par ma personne :)
| 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.
Je serais tenté de dire que c'est une bonne chose que le compilateur ait râlé et que tu ne connaissais pas à l'époque ce qui fait marcher auto_ptr.
Je serais tente d'etre d'accord avec toi et d'ailleur meme si je me coucherais moins bete ce soir ce hack ne sera pas a mon avis utilise avant longtemps par ma personne :)
-- Frederic Py
Christophe de Vienne
wrote:
il y a dans la culture française une tendance à chercher trop dans des mots individuels, sans prendre en considération le tout.
Peut-être mais c'est pas une façon de le dire ;-)
-- Christophe de Vienne Experience is something you don't get until just after you need it. Oliver's Law.
kanze@gabi-soft.fr wrote:
il y a dans la culture française une tendance à
chercher trop dans des mots individuels, sans prendre en considération
le tout.
Peut-être mais c'est pas une façon de le dire ;-)
--
Christophe de Vienne
Experience is something you don't get until just after you need it.
Oliver's Law.
il y a dans la culture française une tendance à chercher trop dans des mots individuels, sans prendre en considération le tout.
Peut-être mais c'est pas une façon de le dire ;-)
-- Christophe de Vienne Experience is something you don't get until just after you need it. Oliver's Law.
kanze
"Alain Naigeon" wrote in message news:<3f165f74$0$17266$...
Donc, le choix d'un langage s'effectue, en principe, sur des bases rationnelles.
Tout à fait. Un expert C++ touche entre 500 et 800 Euros par jour, sinon plus (selon le marché -- actuellement, les prix se tassent vers le bas de l'échelle). Un expert Modula-3 touche les indemnités de chomage -- peut-être 40 Euros par jour ? C'est une base très rationnelle, non ?
-- 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:<3f165f74$0$17266$626a54ce@news.free.fr>...
Donc, le choix d'un langage s'effectue, en principe, sur des bases
rationnelles.
Tout à fait. Un expert C++ touche entre 500 et 800 Euros par jour, sinon
plus (selon le marché -- actuellement, les prix se tassent vers le bas
de l'échelle). Un expert Modula-3 touche les indemnités de chomage --
peut-être 40 Euros par jour ? C'est une base très rationnelle, non ?
--
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
"Alain Naigeon" wrote in message news:<3f165f74$0$17266$...
Donc, le choix d'un langage s'effectue, en principe, sur des bases rationnelles.
Tout à fait. Un expert C++ touche entre 500 et 800 Euros par jour, sinon plus (selon le marché -- actuellement, les prix se tassent vers le bas de l'échelle). Un expert Modula-3 touche les indemnités de chomage -- peut-être 40 Euros par jour ? C'est une base très rationnelle, non ?
-- 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
kanze
"Christophe Lephay" wrote in message news:<bf5n9m$8pb$...
a écrit dans le message de news:
Il y a beaucoup de problèmes avec C++, mais les plus grands viennent prèsque tous de l'héritage C. En revanche, les plus grands sont tels qu'on aurait du mal à s'en défaire : le syntaxe des declarations, des conversions implicites dans tous les sens...
Peut-être que les plus grands problèmes du C++ viennent de l'héritage du C, mais, d'un autre coté, les plus grands problèmes du C n'existent plus en C++ ;)
C++ donne des moyens pour maîtriser ces problèmes (en partie, parce que côté syntaxe de déclaration...). Il ne les supprime pas -- si tu veux déréférencier un pointeur non-initialisé ne C++, c'est aussi facile qu'en C.
Si tu ne veux pas le faire, évidemment, les constructeurs peuvent aider beaucoup. Mais c'est un moyen à maîtriser la risque ; la risque y est toujours.
-- 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
"Christophe Lephay" <christophe-lephay@wanadoo.fr> wrote in message
news:<bf5n9m$8pb$1@news-reader6.wanadoo.fr>...
<kanze@gabi-soft.fr> a écrit dans le message de
news:d6652001.0307170006.225658b3@posting.google.com...
Il y a beaucoup de problèmes avec C++, mais les plus grands viennent
prèsque tous de l'héritage C. En revanche, les plus grands sont tels
qu'on aurait du mal à s'en défaire : le syntaxe des declarations,
des conversions implicites dans tous les sens...
Peut-être que les plus grands problèmes du C++ viennent de l'héritage
du C, mais, d'un autre coté, les plus grands problèmes du C n'existent
plus en C++ ;)
C++ donne des moyens pour maîtriser ces problèmes (en partie, parce que
côté syntaxe de déclaration...). Il ne les supprime pas -- si tu veux
déréférencier un pointeur non-initialisé ne C++, c'est aussi facile
qu'en C.
Si tu ne veux pas le faire, évidemment, les constructeurs peuvent aider
beaucoup. Mais c'est un moyen à maîtriser la risque ; la risque y est
toujours.
--
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
"Christophe Lephay" wrote in message news:<bf5n9m$8pb$...
a écrit dans le message de news:
Il y a beaucoup de problèmes avec C++, mais les plus grands viennent prèsque tous de l'héritage C. En revanche, les plus grands sont tels qu'on aurait du mal à s'en défaire : le syntaxe des declarations, des conversions implicites dans tous les sens...
Peut-être que les plus grands problèmes du C++ viennent de l'héritage du C, mais, d'un autre coté, les plus grands problèmes du C n'existent plus en C++ ;)
C++ donne des moyens pour maîtriser ces problèmes (en partie, parce que côté syntaxe de déclaration...). Il ne les supprime pas -- si tu veux déréférencier un pointeur non-initialisé ne C++, c'est aussi facile qu'en C.
Si tu ne veux pas le faire, évidemment, les constructeurs peuvent aider beaucoup. Mais c'est un moyen à maîtriser la risque ; la risque y est toujours.
-- 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
Gabriel Dos Reis
Christophe de Vienne writes:
| wrote: | | > il y a dans la culture française une tendance à | > chercher trop dans des mots individuels, sans prendre en considération | > le tout. | | Peut-être mais c'est pas une façon de le dire ;-)
toi, tu es en train de chercher trop dans des mots inidividuels, sans prendre considération le tout. Hystérique ! <g>
-- Gaby
Christophe de Vienne <cdevienne@alphacent.com> writes:
| kanze@gabi-soft.fr wrote:
|
| > il y a dans la culture française une tendance à
| > chercher trop dans des mots individuels, sans prendre en considération
| > le tout.
|
| Peut-être mais c'est pas une façon de le dire ;-)
toi, tu es en train de chercher trop dans des mots inidividuels, sans
prendre considération le tout. Hystérique ! <g>
| wrote: | | > il y a dans la culture française une tendance à | > chercher trop dans des mots individuels, sans prendre en considération | > le tout. | | Peut-être mais c'est pas une façon de le dire ;-)
toi, tu es en train de chercher trop dans des mots inidividuels, sans prendre considération le tout. Hystérique ! <g>
-- Gaby
Gabriel Dos Reis
"Alain Naigeon" writes:
| "Jean-Marc Bourguet" a écrit dans le message news: | | > Arnaud Meurgues writes: | > | > > Alain Naigeon wrote: | > > | > > > En Pascal je définissais deux types intervalle, différents bien | > > > que prenant leurs valeurs sur le même sous-ensemble des | > > > entiers, de sorte que toutes les erreurs possibles étaient | > > > diagnostiquées dès la compilation. | > > | > > Heu... Excepté qu'on passe rarement une valeur connue à la | > > compilation, mais plus souvent une variable dont le contenu ne peut | > > être connu qu'à l'exécution. | > > | > > Ai-je raté quelque chose ? | > | > 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. | | J'aurais voulu pouvoir dire ça de façon aussi claire et concise !
Si c'est ce que tu as voulu dire, la même chose (erreur de compilation) est possible en C++/
| Mais puisqu'il faut que je tartine du code pour avoir le droit de | le dire, eh bien, je vais tartiner :-)
:-)
-- Gaby
"Alain Naigeon" <anaigeon@free.fr> writes:
| "Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message news:
| pxboezt46a9.fsf@news.bourguet.org...
| > Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> writes:
| >
| > > Alain Naigeon wrote:
| > >
| > > > En Pascal je définissais deux types intervalle, différents bien
| > > > que prenant leurs valeurs sur le même sous-ensemble des
| > > > entiers, de sorte que toutes les erreurs possibles étaient
| > > > diagnostiquées dès la compilation.
| > >
| > > Heu... Excepté qu'on passe rarement une valeur connue à la
| > > compilation, mais plus souvent une variable dont le contenu ne peut
| > > être connu qu'à l'exécution.
| > >
| > > Ai-je raté quelque chose ?
| >
| > 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.
|
| J'aurais voulu pouvoir dire ça de façon aussi claire et concise !
Si c'est ce que tu as voulu dire, la même chose (erreur de
compilation) est possible en C++/
| Mais puisqu'il faut que je tartine du code pour avoir le droit de
| le dire, eh bien, je vais tartiner :-)
| "Jean-Marc Bourguet" a écrit dans le message news: | | > Arnaud Meurgues writes: | > | > > Alain Naigeon wrote: | > > | > > > En Pascal je définissais deux types intervalle, différents bien | > > > que prenant leurs valeurs sur le même sous-ensemble des | > > > entiers, de sorte que toutes les erreurs possibles étaient | > > > diagnostiquées dès la compilation. | > > | > > Heu... Excepté qu'on passe rarement une valeur connue à la | > > compilation, mais plus souvent une variable dont le contenu ne peut | > > être connu qu'à l'exécution. | > > | > > Ai-je raté quelque chose ? | > | > 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. | | J'aurais voulu pouvoir dire ça de façon aussi claire et concise !
Si c'est ce que tu as voulu dire, la même chose (erreur de compilation) est possible en C++/
| Mais puisqu'il faut que je tartine du code pour avoir le droit de | le dire, eh bien, je vais tartiner :-)
:-)
-- Gaby
Alain Naigeon
"Jean-Marc Bourguet" a écrit dans le message news:
Arnaud Meurgues writes:
Alain Naigeon wrote:
En Pascal je définissais deux types intervalle, différents bien que prenant leurs valeurs sur le même sous-ensemble des entiers, de sorte que toutes les erreurs possibles étaient diagnostiquées dès la compilation.
Heu... Excepté qu'on passe rarement une valeur connue à la compilation, mais plus souvent une variable dont le contenu ne peut être connu qu'à l'exécution.
Ai-je raté quelque chose ?
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.
J'aurais voulu pouvoir dire ça de façon aussi claire et concise ! Mais puisqu'il faut que je tartine du code pour avoir le droit de le dire, eh bien, je vais tartiner :-)
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message news:
pxboezt46a9.fsf@news.bourguet.org...
En Pascal je définissais deux types intervalle, différents bien
que prenant leurs valeurs sur le même sous-ensemble des
entiers, de sorte que toutes les erreurs possibles étaient
diagnostiquées dès la compilation.
Heu... Excepté qu'on passe rarement une valeur connue à la
compilation, mais plus souvent une variable dont le contenu ne peut
être connu qu'à l'exécution.
Ai-je raté quelque chose ?
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.
J'aurais voulu pouvoir dire ça de façon aussi claire et concise !
Mais puisqu'il faut que je tartine du code pour avoir le droit de
le dire, eh bien, je vais tartiner :-)
--
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
"Jean-Marc Bourguet" a écrit dans le message news:
Arnaud Meurgues writes:
Alain Naigeon wrote:
En Pascal je définissais deux types intervalle, différents bien que prenant leurs valeurs sur le même sous-ensemble des entiers, de sorte que toutes les erreurs possibles étaient diagnostiquées dès la compilation.
Heu... Excepté qu'on passe rarement une valeur connue à la compilation, mais plus souvent une variable dont le contenu ne peut être connu qu'à l'exécution.
Ai-je raté quelque chose ?
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.
J'aurais voulu pouvoir dire ça de façon aussi claire et concise ! Mais puisqu'il faut que je tartine du code pour avoir le droit de le dire, eh bien, je vais tartiner :-)
--
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
Arnaud Meurgues writes:
| 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 ?
Dans le contexte de la discussion de ce fil-ci : oui. Initialisation de paramètre et retour participe du même principe.
Sur un autre plan, l'interface de auto_ptr<> fait croire qu'on peut l'utiliser aussi simplement que d'autres types simples sans se soucier de quoi que ce soit. Pour moi c'est plus proche de Machiavel que de Murphy.
| 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.
Pour moi, le problème vient de ce que l'interface d'auto_ptr fait croire qu'on peut l'utiliser naïvement sans problème. Cela n'est pas du Murphy.
| 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) ?
il y a eu beaucoup de versions d'auto_ptr<>, la seule « bonne » dont je me souviens bien est celle adoptée le 27 Novembre 1997 par le comité.
| 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 ?
Dans le contexte de la discussion de ce fil-ci : oui. Initialisation de
paramètre et retour participe du même principe.
Sur un autre plan, l'interface de auto_ptr<> fait croire qu'on peut
l'utiliser aussi simplement que d'autres types simples sans se soucier
de quoi que ce soit. Pour moi c'est plus proche de Machiavel que de Murphy.
| 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.
Pour moi, le problème vient de ce que l'interface d'auto_ptr fait
croire qu'on peut l'utiliser naïvement sans problème. Cela n'est pas
du Murphy.
| 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) ?
il y a eu beaucoup de versions d'auto_ptr<>, la seule « bonne »
dont je me souviens bien est celle adoptée le 27 Novembre 1997 par le
comité.
| 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 ?
Dans le contexte de la discussion de ce fil-ci : oui. Initialisation de paramètre et retour participe du même principe.
Sur un autre plan, l'interface de auto_ptr<> fait croire qu'on peut l'utiliser aussi simplement que d'autres types simples sans se soucier de quoi que ce soit. Pour moi c'est plus proche de Machiavel que de Murphy.
| 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.
Pour moi, le problème vient de ce que l'interface d'auto_ptr fait croire qu'on peut l'utiliser naïvement sans problème. Cela n'est pas du Murphy.
| 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) ?
il y a eu beaucoup de versions d'auto_ptr<>, la seule « bonne » dont je me souviens bien est celle adoptée le 27 Novembre 1997 par le comité.
