bonjour
j'ai besoin de faire une liste d'objet qui se d=E9truiront automatiquemen=
t.
Pour cel=E0 en utilisant la STL, j'utilise une list d'auto_ptr.
plus pr=E9cis=E9ment:
class A;
typedef auto_ptr<A> auto_A;
typedef list<auto_ptr> list_A;
ainsi, quand j'ajoute un =E9l=E9ment, il se cr=E9=E9 (le constructeur est=
=20
appel=E9), puis je l'ajoute dans la list (pas de copie, pas de=20
constructeur appell=E9). Puis =E0 la destruction de la list (lors d'un er=
ase=20
ou d'un pop_*), le destructeur est appell=E9.
J'ai l'impression que =E7a marche mais mon programme semble instable de=20
temps en temps j'aimerais savoir si =E7a peu venir de cette m=E9thode=20
(est-elle vraiment propre?). Y a t il un autre moyen?
Avant j'utilisais une list<A> qui marchait mais pour ajouter un =E9l=E9me=
nt=20
il fallait le cr=E9er, puis lors d'un push_*, il en faisait la copie, et =
ensuite pouvait etre d=E9truit automatiquement.
Je me demande si en utilisant les allocators =E7a ne marcherais pas.
Gabriel Dos Reis said the following on 08/20/03 08:18:
Gaetan writes:
[...]
| Il n'y a pas moyen en utilisant que la STL de spécifier qu'il faut | appeler le destructeur de chaque élément dans une liste de pointeur...
On peut savoir pourquoi tu veux mettre des pointeurs dans ta liste au lieu d'y mettre directement les objets pointés ?
A priori ça doit être pour contenir des objets issus de classes filles d'une classe generique et faire du polymorphisme ... sinon je ne voit pas l'interet
-- Frederic Py
Gabriel Dos Reis said the following on 08/20/03 08:18:
Gaetan <gaetan.semet@free.fr> writes:
[...]
| Il n'y a pas moyen en utilisant que la STL de spécifier qu'il faut
| appeler le destructeur de chaque élément dans une liste de pointeur...
On peut savoir pourquoi tu veux mettre des pointeurs dans ta liste au
lieu d'y mettre directement les objets pointés ?
A priori ça doit être pour contenir des objets issus de classes filles
d'une classe generique et faire du polymorphisme ... sinon je ne voit
pas l'interet
Gabriel Dos Reis said the following on 08/20/03 08:18:
Gaetan writes:
[...]
| Il n'y a pas moyen en utilisant que la STL de spécifier qu'il faut | appeler le destructeur de chaque élément dans une liste de pointeur...
On peut savoir pourquoi tu veux mettre des pointeurs dans ta liste au lieu d'y mettre directement les objets pointés ?
A priori ça doit être pour contenir des objets issus de classes filles d'une classe generique et faire du polymorphisme ... sinon je ne voit pas l'interet
-- Frederic Py
Arnaud Meurgues
Frederic Py wrote:
On peut savoir pourquoi tu veux mettre des pointeurs dans ta liste au lieu d'y mettre directement les objets pointés ? A priori ça doit être pour contenir des objets issus de classes filles
d'une classe generique et faire du polymorphisme ... sinon je ne voit pas l'interet
Même sans polymorphisme, si ce ne sont pas des objets à sémantique de valeur, il me parait difficile de les manipuler autrement que par des pointeurs (intelligents ou pas).
Arnaud
Frederic Py wrote:
On peut savoir pourquoi tu veux mettre des pointeurs dans ta liste au
lieu d'y mettre directement les objets pointés ?
A priori ça doit être pour contenir des objets issus de classes filles
d'une classe generique et faire du polymorphisme ... sinon je ne voit
pas l'interet
Même sans polymorphisme, si ce ne sont pas des objets à sémantique de
valeur, il me parait difficile de les manipuler autrement que par des
pointeurs (intelligents ou pas).
On peut savoir pourquoi tu veux mettre des pointeurs dans ta liste au lieu d'y mettre directement les objets pointés ? A priori ça doit être pour contenir des objets issus de classes filles
d'une classe generique et faire du polymorphisme ... sinon je ne voit pas l'interet
Même sans polymorphisme, si ce ne sont pas des objets à sémantique de valeur, il me parait difficile de les manipuler autrement que par des pointeurs (intelligents ou pas).
Arnaud
Gabriel Dos Reis
Arnaud Meurgues writes:
| Frederic Py wrote: | | >> On peut savoir pourquoi tu veux mettre des pointeurs dans ta liste au | >> lieu d'y mettre directement les objets pointés ? | > A priori ça doit être pour contenir des objets issus de classes | > filles d'une classe generique et faire du polymorphisme ... sinon je | > ne voit pas l'interet | | Même sans polymorphisme, si ce ne sont pas des objets à sémantique de | valeur, il me parait difficile de les manipuler autrement que par des | pointeurs (intelligents ou pas).
La question n'est pas que je ne connais pas de cas où mettre directement l'objet dans un container est problématique. La question est plutôt, vu l'expérience relativement récente de Gaétan, de savoir quel genre d'objet il crée. Que ce qu'il fait ait d'intérêt ou non est une autre question.
| Frederic Py wrote:
|
| >> On peut savoir pourquoi tu veux mettre des pointeurs dans ta liste au
| >> lieu d'y mettre directement les objets pointés ?
| > A priori ça doit être pour contenir des objets issus de classes
| > filles d'une classe generique et faire du polymorphisme ... sinon je
| > ne voit pas l'interet
|
| Même sans polymorphisme, si ce ne sont pas des objets à sémantique de
| valeur, il me parait difficile de les manipuler autrement que par des
| pointeurs (intelligents ou pas).
La question n'est pas que je ne connais pas de cas où mettre
directement l'objet dans un container est problématique. La question
est plutôt, vu l'expérience relativement récente de Gaétan, de savoir
quel genre d'objet il crée. Que ce qu'il fait ait d'intérêt ou non est
une autre question.
| Frederic Py wrote: | | >> On peut savoir pourquoi tu veux mettre des pointeurs dans ta liste au | >> lieu d'y mettre directement les objets pointés ? | > A priori ça doit être pour contenir des objets issus de classes | > filles d'une classe generique et faire du polymorphisme ... sinon je | > ne voit pas l'interet | | Même sans polymorphisme, si ce ne sont pas des objets à sémantique de | valeur, il me parait difficile de les manipuler autrement que par des | pointeurs (intelligents ou pas).
La question n'est pas que je ne connais pas de cas où mettre directement l'objet dans un container est problématique. La question est plutôt, vu l'expérience relativement récente de Gaétan, de savoir quel genre d'objet il crée. Que ce qu'il fait ait d'intérêt ou non est une autre question.
Fabien LE LEZ
On Wed, 20 Aug 2003 15:27:41 +0200, Gaetan wrote:
Donc il y a un objet construit pour "rien"...
Et est-ce problématique ?
-- 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 Wed, 20 Aug 2003 15:27:41 +0200, Gaetan <gaetan.semet@free.fr>
wrote:
Donc il y a un objet construit pour "rien"...
Et est-ce problématique ?
--
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
-- 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
Gaetan
Fabien LE LEZ wrote:
On Wed, 20 Aug 2003 15:27:41 +0200, Gaetan wrote:
Donc il y a un objet construit pour "rien"...
Et est-ce problématique ?
oui dans le sens ou il peut y avoir + rapide (et je ne trouve pas celà beau): on ne créé qu'une fois l'objet. Par contre, si on me dit que c'est comme ça qu'on programme (bien) en C++, je retournerais à ma premiere methode.
--
~~ Gaetan ~~ http://www.xeberon.net
Fabien LE LEZ wrote:
On Wed, 20 Aug 2003 15:27:41 +0200, Gaetan <gaetan.semet@free.fr>
wrote:
Donc il y a un objet construit pour "rien"...
Et est-ce problématique ?
oui dans le sens ou il peut y avoir + rapide (et je ne trouve pas celà
beau): on ne créé qu'une fois l'objet.
Par contre, si on me dit que c'est comme ça qu'on programme (bien) en
C++, je retournerais à ma premiere methode.
oui dans le sens ou il peut y avoir + rapide (et je ne trouve pas celà beau): on ne créé qu'une fois l'objet. Par contre, si on me dit que c'est comme ça qu'on programme (bien) en C++, je retournerais à ma premiere methode.
--
~~ Gaetan ~~ http://www.xeberon.net
Christophe Lephay
"Fabien LE LEZ" a écrit dans le message de news:
On Wed, 20 Aug 2003 17:42:47 +0200, Gaetan wrote:
oui dans le sens ou il peut y avoir + rapide (et je ne trouve pas celà beau): on ne créé qu'une fois l'objet.
Commence par programmer proprement, de façon à faire un programme qui fonctionne. Une fois qu'il fonctionne, si tu t'aperçois qu'il est trop lent, tu pourras commencer un travail d'optimisation.
D'autant plus qu'on ne peut pas supposer qu'une copie occasionnelle d'objet ait un impact plus élevé que le fait d'y accéder systématiquement vua un pointeur, en particulier un pointeur intelligent.
Même si tu (Gaetan) connais bien les données que tu manipules, et que tu peux partir de l'à priori que c'est plus rapide de manipuler tes données via un pointeur, un profiler fournit parfois des informations contre toute attente.
Et comme l'a dit Fabien, les peformances sont rarement la problématique principale, contrairement à la robustesse. En l'occurrence, les problèmes que tu rencontres actuellement sont une bonne indication sur les considérations à favoriser ;)
Chris
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news:le67kvcvu2d591ef47rrs1u2etokap2iao@4ax.com...
On Wed, 20 Aug 2003 17:42:47 +0200, Gaetan <gaetan.semet@free.fr>
wrote:
oui dans le sens ou il peut y avoir + rapide (et je ne trouve pas celà
beau): on ne créé qu'une fois l'objet.
Commence par programmer proprement, de façon à faire un programme qui
fonctionne. Une fois qu'il fonctionne, si tu t'aperçois qu'il est trop
lent, tu pourras commencer un travail d'optimisation.
D'autant plus qu'on ne peut pas supposer qu'une copie occasionnelle d'objet
ait un impact plus élevé que le fait d'y accéder systématiquement vua un
pointeur, en particulier un pointeur intelligent.
Même si tu (Gaetan) connais bien les données que tu manipules, et que tu
peux partir de l'à priori que c'est plus rapide de manipuler tes données via
un pointeur, un profiler fournit parfois des informations contre toute
attente.
Et comme l'a dit Fabien, les peformances sont rarement la problématique
principale, contrairement à la robustesse. En l'occurrence, les problèmes
que tu rencontres actuellement sont une bonne indication sur les
considérations à favoriser ;)
oui dans le sens ou il peut y avoir + rapide (et je ne trouve pas celà beau): on ne créé qu'une fois l'objet.
Commence par programmer proprement, de façon à faire un programme qui fonctionne. Une fois qu'il fonctionne, si tu t'aperçois qu'il est trop lent, tu pourras commencer un travail d'optimisation.
D'autant plus qu'on ne peut pas supposer qu'une copie occasionnelle d'objet ait un impact plus élevé que le fait d'y accéder systématiquement vua un pointeur, en particulier un pointeur intelligent.
Même si tu (Gaetan) connais bien les données que tu manipules, et que tu peux partir de l'à priori que c'est plus rapide de manipuler tes données via un pointeur, un profiler fournit parfois des informations contre toute attente.
Et comme l'a dit Fabien, les peformances sont rarement la problématique principale, contrairement à la robustesse. En l'occurrence, les problèmes que tu rencontres actuellement sont une bonne indication sur les considérations à favoriser ;)
Chris
Gaetan
Commence par programmer proprement, de façon à faire un programme q ui fonctionne. Une fois qu'il fonctionne, si tu t'aperçois qu'il est tro p lent, tu pourras commencer un travail d'optimisation.
ok
D'autant plus qu'on ne peut pas supposer qu'une copie occasionnelle d'o bjet ait un impact plus élevé que le fait d'y accéder systématiqueme nt vua un pointeur, en particulier un pointeur intelligent.
Même si tu (Gaetan) connais bien les données que tu manipules, et q ue tu peux partir de l'à priori que c'est plus rapide de manipuler tes donn ées via un pointeur, un profiler fournit parfois des informations contre toute attente.
Et comme l'a dit Fabien, les peformances sont rarement la problématiq ue principale, contrairement à la robustesse. En l'occurrence, les probl èmes que tu rencontres actuellement sont une bonne indication sur les considérations à favoriser ;)
bon bon mais je suis déçut dans un sens que la STL ne permette pas ce que je disais. Donc mieux vaux faire une liste d'objet quitte à faire une recopie au lieu d'une simple allocation directement. N'y a t il pas moyen non plus d'avoir une fonction push qui créé l'ob jet (donc on lui donnerais les arguments à transmettre à l'objet du style (exemple): list_A.push_back(param1n param2,...) en fonction des constructeurs de l'élément A. Par exemple si on fait une classe dérivée de list ça devrait marche r non?
Merci de votre aide et d'avoir éclaicit ma lanterne.
--
~~ Gaetan ~~ http://www.xeberon.net
Commence par programmer proprement, de façon à faire un programme q ui
fonctionne. Une fois qu'il fonctionne, si tu t'aperçois qu'il est tro p
lent, tu pourras commencer un travail d'optimisation.
ok
D'autant plus qu'on ne peut pas supposer qu'une copie occasionnelle d'o bjet
ait un impact plus élevé que le fait d'y accéder systématiqueme nt vua un
pointeur, en particulier un pointeur intelligent.
Même si tu (Gaetan) connais bien les données que tu manipules, et q ue tu
peux partir de l'à priori que c'est plus rapide de manipuler tes donn ées via
un pointeur, un profiler fournit parfois des informations contre toute
attente.
Et comme l'a dit Fabien, les peformances sont rarement la problématiq ue
principale, contrairement à la robustesse. En l'occurrence, les probl èmes
que tu rencontres actuellement sont une bonne indication sur les
considérations à favoriser ;)
bon bon mais je suis déçut dans un sens que la STL ne permette pas ce
que je disais.
Donc mieux vaux faire une liste d'objet quitte à faire une recopie au
lieu d'une simple allocation directement.
N'y a t il pas moyen non plus d'avoir une fonction push qui créé l'ob jet
(donc on lui donnerais les arguments à transmettre à l'objet
du style (exemple):
list_A.push_back(param1n param2,...) en fonction des constructeurs de
l'élément A.
Par exemple si on fait une classe dérivée de list ça devrait marche r non?
Merci de votre aide et d'avoir éclaicit ma lanterne.
Commence par programmer proprement, de façon à faire un programme q ui fonctionne. Une fois qu'il fonctionne, si tu t'aperçois qu'il est tro p lent, tu pourras commencer un travail d'optimisation.
ok
D'autant plus qu'on ne peut pas supposer qu'une copie occasionnelle d'o bjet ait un impact plus élevé que le fait d'y accéder systématiqueme nt vua un pointeur, en particulier un pointeur intelligent.
Même si tu (Gaetan) connais bien les données que tu manipules, et q ue tu peux partir de l'à priori que c'est plus rapide de manipuler tes donn ées via un pointeur, un profiler fournit parfois des informations contre toute attente.
Et comme l'a dit Fabien, les peformances sont rarement la problématiq ue principale, contrairement à la robustesse. En l'occurrence, les probl èmes que tu rencontres actuellement sont une bonne indication sur les considérations à favoriser ;)
bon bon mais je suis déçut dans un sens que la STL ne permette pas ce que je disais. Donc mieux vaux faire une liste d'objet quitte à faire une recopie au lieu d'une simple allocation directement. N'y a t il pas moyen non plus d'avoir une fonction push qui créé l'ob jet (donc on lui donnerais les arguments à transmettre à l'objet du style (exemple): list_A.push_back(param1n param2,...) en fonction des constructeurs de l'élément A. Par exemple si on fait une classe dérivée de list ça devrait marche r non?
Merci de votre aide et d'avoir éclaicit ma lanterne.
--
~~ Gaetan ~~ http://www.xeberon.net
Gabriel Dos Reis
Gaetan writes:
[...]
| ça marche très bien MAIS il y a un objet temporaire qui est créer et | j'aimais éviter ça.
Pourquoi c'esyt si important ?
-- Gaby
Gaetan <gaetan.semet@free.fr> writes:
[...]
| ça marche très bien MAIS il y a un objet temporaire qui est créer et
| j'aimais éviter ça.
| ça marche très bien MAIS il y a un objet temporaire qui est cré er et | j'aimais éviter ça.
Pourquoi c'esyt si important ?
-- Gaby
c'est pas si important que ça c'est juste que je trouvais ça pas top de créé un objet temporaire comme ça. C'était juste par curiosité
--
~~ Gaetan ~~ http://www.xeberon.net
Christophe Lephay
"Gaetan" a écrit dans le message de news:3f43ab17$0$16161$
bon bon mais je suis déçut dans un sens que la STL ne permette pas ce que je disais.
C'est vrai que c'est un reproche qui revient souvent. Certains ici ont évoqué l'idée que boost était assez représentatif de ce que pourrait être la prochaine version de la SL...
Donc mieux vaux faire une liste d'objet quitte à faire une recopie au lieu d'une simple allocation directement.
C'est à voir. La première question à se poser, c'est de savoir si ta classe est sensée supporter une sémantique de valeur ou non. Si c'est le cas, c'est ce qu'il faut faire. Sinon, il vaut mieux continuer à passer par les pointeurs, soit en ne laissant pas aux conteneurs la responsabilité de la désallocation, soit en utilisant des pointeurs intelligents que tu les développes toi-même ou que tu utilises ceux d'une bibliothèque tierce.
N'y a t il pas moyen non plus d'avoir une fonction push qui créé l'objet (donc on lui donnerais les arguments à transmettre à l'objet du style (exemple): list_A.push_back(param1n param2,...) en fonction des constructeurs de l'élément A.
C'est difficilement réalisable dans la mesure où le conteneur ne sait rien des constructeurs des objets qu'il contient, quels sont ses paramètres ni leur type. Les conteneurs de la SL sont adaptés aux besoins les plus courant, mais ne sauraient les couvrir tous. Il y a un moment où il faut retrousser les manches ;)
Par exemple si on fait une classe dérivée de list ça devrait marcher non?
Tu mets le doigt sur une autre idée de la STL : les conteneurs ne sont pas prévus pour qu'on les utilises comme classes de base. Il n'y a par contre aucune contre-indication pour en réutiliser les fonctionnalités, que ce soit par l'héritage privé ou par composition (une classe qui a un conteneur comme donnée membre).
Chris
"Gaetan" <gaetan.semet@free.fr> a écrit dans le message de
news:3f43ab17$0$16161$626a54ce@news.free.fr...
bon bon mais je suis déçut dans un sens que la STL ne permette pas ce
que je disais.
C'est vrai que c'est un reproche qui revient souvent. Certains ici ont
évoqué l'idée que boost était assez représentatif de ce que pourrait être la
prochaine version de la SL...
Donc mieux vaux faire une liste d'objet quitte à faire une recopie au
lieu d'une simple allocation directement.
C'est à voir. La première question à se poser, c'est de savoir si ta classe
est sensée supporter une sémantique de valeur ou non. Si c'est le cas, c'est
ce qu'il faut faire. Sinon, il vaut mieux continuer à passer par les
pointeurs, soit en ne laissant pas aux conteneurs la responsabilité de la
désallocation, soit en utilisant des pointeurs intelligents que tu les
développes toi-même ou que tu utilises ceux d'une bibliothèque tierce.
N'y a t il pas moyen non plus d'avoir une fonction push qui créé l'objet
(donc on lui donnerais les arguments à transmettre à l'objet
du style (exemple):
list_A.push_back(param1n param2,...) en fonction des constructeurs de
l'élément A.
C'est difficilement réalisable dans la mesure où le conteneur ne sait rien
des constructeurs des objets qu'il contient, quels sont ses paramètres ni
leur type. Les conteneurs de la SL sont adaptés aux besoins les plus
courant, mais ne sauraient les couvrir tous. Il y a un moment où il faut
retrousser les manches ;)
Par exemple si on fait une classe dérivée de list ça devrait marcher non?
Tu mets le doigt sur une autre idée de la STL : les conteneurs ne sont pas
prévus pour qu'on les utilises comme classes de base. Il n'y a par contre
aucune contre-indication pour en réutiliser les fonctionnalités, que ce soit
par l'héritage privé ou par composition (une classe qui a un conteneur comme
donnée membre).
"Gaetan" a écrit dans le message de news:3f43ab17$0$16161$
bon bon mais je suis déçut dans un sens que la STL ne permette pas ce que je disais.
C'est vrai que c'est un reproche qui revient souvent. Certains ici ont évoqué l'idée que boost était assez représentatif de ce que pourrait être la prochaine version de la SL...
Donc mieux vaux faire une liste d'objet quitte à faire une recopie au lieu d'une simple allocation directement.
C'est à voir. La première question à se poser, c'est de savoir si ta classe est sensée supporter une sémantique de valeur ou non. Si c'est le cas, c'est ce qu'il faut faire. Sinon, il vaut mieux continuer à passer par les pointeurs, soit en ne laissant pas aux conteneurs la responsabilité de la désallocation, soit en utilisant des pointeurs intelligents que tu les développes toi-même ou que tu utilises ceux d'une bibliothèque tierce.
N'y a t il pas moyen non plus d'avoir une fonction push qui créé l'objet (donc on lui donnerais les arguments à transmettre à l'objet du style (exemple): list_A.push_back(param1n param2,...) en fonction des constructeurs de l'élément A.
C'est difficilement réalisable dans la mesure où le conteneur ne sait rien des constructeurs des objets qu'il contient, quels sont ses paramètres ni leur type. Les conteneurs de la SL sont adaptés aux besoins les plus courant, mais ne sauraient les couvrir tous. Il y a un moment où il faut retrousser les manches ;)
Par exemple si on fait une classe dérivée de list ça devrait marcher non?
Tu mets le doigt sur une autre idée de la STL : les conteneurs ne sont pas prévus pour qu'on les utilises comme classes de base. Il n'y a par contre aucune contre-indication pour en réutiliser les fonctionnalités, que ce soit par l'héritage privé ou par composition (une classe qui a un conteneur comme donnée membre).
