J'ai du mal à comprendre ce qui ne va pas donc je vous montre mon code
simplifié à l'extrème. (au passage c'est la première fois que j'utilise
aut_ptr)
J'utilise une bibliothèque qui définie la class QwtData et ayant pour
membres :
virtual QwtData * copy () const =0
virtual size_t size () const =0
virtual double x (size_t i) const =0
virtual double y (size_t i) const =0
virtual QwtDoubleRect boundingRect () const
Soit ma class BTest qui est l'objet de base :
struct BTest
{
// Vide pour l'exemple
};
Puis la définition de ReTest qui hérite de QwtData :
class ReTest : public QwtData
{
public:
ReTest( std::auto_ptr<BTest> pt )
: t(pt) {}
QwtData* copy() const
{
return new ReTest(t); // c'est la ligne 21
}
size_t size() const
{
return 0;
}
double y(size_t ) const
{
return 0;
}
double x(size_t ) const
{
return 0;
}
std::auto_ptr<BTest> t;
};
graph/plot.cpp: In member function `virtual QwtData*
<unnamed>::ReTest::copy() const':
graph/plot.cpp:21: error: passing `const
std::auto_ptr<<unnamed>::BTest>' as `this' argument of `
std::auto_ptr<_Tp>::operator std::auto_ptr_ref<_Tp1>() [with _Tp1 =
<unnamed>::BTest, _Tp = <unna
med>::BTest]' discards qualifiers
graph/plot.cpp:21: error: initializing argument 1 of
`<unnamed>::ReTest::ReTest(std::auto_ptr<<
unnamed>::BTest>)'
J'ai essayé de torturer dans tous les sens la définition de
std::auto_ptr<BTest> t par
std::auto_ptr<const BTest> t, std::auto_ptr<const BTest> const t,
std::auto_ptr<BTest> const t,
mais rien ne change.
Avez vous une idée pour que je m'en sorte ?
Sans auto_ptr tout compile bien.
On Thu, 25 Aug 2005 16:35:19 +0200, "leroux_philippe at yahoo.fr" <"leroux_philippe at yahoo.fr">:
(au passage c'est la première fois que j'utilise aut_ptr)
M'étonne pas. En pratique, c'est rarement utile, ce machin. AMHA tu devrais plutôt t'intéresser à boost::shared_ptr<>, beaucoup plus utilisé.
François
Bonjour,
J'ai du mal à comprendre ce qui ne va pas donc je vous montre mon code simplifié à l'extrème. (au passage c'est la première fois que j'utilise aut_ptr)
[...]
Puis la définition de ReTest qui hérite de QwtData : class ReTest : public QwtData { public: ReTest( std::auto_ptr<BTest> pt ) : t(pt) {}
QwtData* copy() const { return new ReTest(t); // c'est la ligne 21 }
std::auto_ptr<BTest> t; };
graph/plot.cpp: In member function `virtual QwtData* <unnamed>::ReTest::copy() const': error
[...]
Avez vous une idée pour que je m'en sorte ? Sans auto_ptr tout compile bien.
la méthode copy essaie de passer au constructeur de ReTest la valeur de la donnée membre t. Pour ce faire, normalement, on passe par le constructeur de copie de la classe auto_ptr. Mais t est const puisque copy est une méthode const, et le constructeur decopie de aut_ptr veut un objet non const pour le modifier, donc ce n'est pas possible.
François
Bonjour,
J'ai du mal à comprendre ce qui ne va pas donc je vous montre mon code
simplifié à l'extrème. (au passage c'est la première fois que j'utilise
aut_ptr)
[...]
Puis la définition de ReTest qui hérite de QwtData :
class ReTest : public QwtData
{
public:
ReTest( std::auto_ptr<BTest> pt )
: t(pt) {}
QwtData* copy() const
{
return new ReTest(t); // c'est la ligne 21
}
std::auto_ptr<BTest> t;
};
graph/plot.cpp: In member function `virtual QwtData*
<unnamed>::ReTest::copy() const': error
[...]
Avez vous une idée pour que je m'en sorte ?
Sans auto_ptr tout compile bien.
la méthode copy essaie de passer au constructeur de ReTest la valeur de
la donnée membre t. Pour ce faire, normalement, on passe par le
constructeur de copie de la classe auto_ptr. Mais t est const puisque
copy est une méthode const, et le constructeur decopie de aut_ptr veut
un objet non const pour le modifier, donc ce n'est pas possible.
J'ai du mal à comprendre ce qui ne va pas donc je vous montre mon code simplifié à l'extrème. (au passage c'est la première fois que j'utilise aut_ptr)
[...]
Puis la définition de ReTest qui hérite de QwtData : class ReTest : public QwtData { public: ReTest( std::auto_ptr<BTest> pt ) : t(pt) {}
QwtData* copy() const { return new ReTest(t); // c'est la ligne 21 }
std::auto_ptr<BTest> t; };
graph/plot.cpp: In member function `virtual QwtData* <unnamed>::ReTest::copy() const': error
[...]
Avez vous une idée pour que je m'en sorte ? Sans auto_ptr tout compile bien.
la méthode copy essaie de passer au constructeur de ReTest la valeur de la donnée membre t. Pour ce faire, normalement, on passe par le constructeur de copie de la classe auto_ptr. Mais t est const puisque copy est une méthode const, et le constructeur decopie de aut_ptr veut un objet non const pour le modifier, donc ce n'est pas possible.
François
kanze
Fabien LE LEZ wrote:
On Thu, 25 Aug 2005 16:35:19 +0200, "leroux_philippe at yahoo.fr" <"leroux_philippe at yahoo.fr">:
(au passage c'est la première fois que j'utilise aut_ptr)
M'étonne pas. En pratique, c'est rarement utile, ce machin. AMHA tu devrais plutôt t'intéresser à boost::shared_ptr<>, beaucoup plus utilisé.
Curieux. Moi, j'utilise auto_ptr beaucoup plus souvent que les shared_ptr. Typiquement, si je ne veux pas de copie profond, c'est que l'objet est immutable. Et si l'objet est immutable, la plupart du temps, je m'arrange à le déclarer quelque part avec une durée de vie statique. C'est encore plus vrai dans un environnement multi-threaded, parce que partager des objets mutables entre plusieurs threads implique tout genre de problèmes. (J'utilise les auto_ptr dans l'interface de la queue de messages entre les threads, justement pour dire à l'utilisateur de ne plus toucher à l'objet une fois qu'il l'a passé à l'autre thread. Même si l'implémentation de la queue se base sur std::deque, ce qui m'impose un passage par des pointeurs bruts.)
La question ici, c'est qu'est-ce qu'il veut comme sémantique. S'il veut qu'un BTest soit partagé entre plusieurs ReTest, shared_ptr est une solution. Si en revanche il veut que chaque instance de ReTest ait sa propre instance de BTest (ce qui est fort probable is BTest n'est pas constante), c'est bien auto_ptr qu'il lui faut. Seulement alors, évidemment, quand il fait la copie, il faut qu'il s'arrange pour copier le BTest aussi :
QwtCopy* ReTest::copy() const { return new ReTest( std::auto_ptr< BTest >( new BTest(*t) ) ) ; }
Le fait que le compilateur émet une erreur est juste -- il a bien oublié quelque chose.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On Thu, 25 Aug 2005 16:35:19 +0200, "leroux_philippe at yahoo.fr"
<"leroux_philippe at yahoo.fr">:
(au passage c'est la première fois que j'utilise
aut_ptr)
M'étonne pas. En pratique, c'est rarement utile, ce machin.
AMHA tu devrais plutôt t'intéresser à boost::shared_ptr<>,
beaucoup plus utilisé.
Curieux. Moi, j'utilise auto_ptr beaucoup plus souvent que les
shared_ptr. Typiquement, si je ne veux pas de copie profond,
c'est que l'objet est immutable. Et si l'objet est immutable, la
plupart du temps, je m'arrange à le déclarer quelque part avec
une durée de vie statique. C'est encore plus vrai dans un
environnement multi-threaded, parce que partager des objets
mutables entre plusieurs threads implique tout genre de
problèmes. (J'utilise les auto_ptr dans l'interface de la queue
de messages entre les threads, justement pour dire à
l'utilisateur de ne plus toucher à l'objet une fois qu'il l'a
passé à l'autre thread. Même si l'implémentation de la queue se
base sur std::deque, ce qui m'impose un passage par des
pointeurs bruts.)
La question ici, c'est qu'est-ce qu'il veut comme sémantique.
S'il veut qu'un BTest soit partagé entre plusieurs ReTest,
shared_ptr est une solution. Si en revanche il veut que chaque
instance de ReTest ait sa propre instance de BTest (ce qui est
fort probable is BTest n'est pas constante), c'est bien auto_ptr
qu'il lui faut. Seulement alors, évidemment, quand il fait la
copie, il faut qu'il s'arrange pour copier le BTest aussi :
QwtCopy*
ReTest::copy() const
{
return new ReTest(
std::auto_ptr< BTest >( new BTest(*t) ) ) ;
}
Le fait que le compilateur émet une erreur est juste -- il a
bien oublié quelque chose.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Thu, 25 Aug 2005 16:35:19 +0200, "leroux_philippe at yahoo.fr" <"leroux_philippe at yahoo.fr">:
(au passage c'est la première fois que j'utilise aut_ptr)
M'étonne pas. En pratique, c'est rarement utile, ce machin. AMHA tu devrais plutôt t'intéresser à boost::shared_ptr<>, beaucoup plus utilisé.
Curieux. Moi, j'utilise auto_ptr beaucoup plus souvent que les shared_ptr. Typiquement, si je ne veux pas de copie profond, c'est que l'objet est immutable. Et si l'objet est immutable, la plupart du temps, je m'arrange à le déclarer quelque part avec une durée de vie statique. C'est encore plus vrai dans un environnement multi-threaded, parce que partager des objets mutables entre plusieurs threads implique tout genre de problèmes. (J'utilise les auto_ptr dans l'interface de la queue de messages entre les threads, justement pour dire à l'utilisateur de ne plus toucher à l'objet une fois qu'il l'a passé à l'autre thread. Même si l'implémentation de la queue se base sur std::deque, ce qui m'impose un passage par des pointeurs bruts.)
La question ici, c'est qu'est-ce qu'il veut comme sémantique. S'il veut qu'un BTest soit partagé entre plusieurs ReTest, shared_ptr est une solution. Si en revanche il veut que chaque instance de ReTest ait sa propre instance de BTest (ce qui est fort probable is BTest n'est pas constante), c'est bien auto_ptr qu'il lui faut. Seulement alors, évidemment, quand il fait la copie, il faut qu'il s'arrange pour copier le BTest aussi :
QwtCopy* ReTest::copy() const { return new ReTest( std::auto_ptr< BTest >( new BTest(*t) ) ) ; }
Le fait que le compilateur émet une erreur est juste -- il a bien oublié quelque chose.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Stan
a écrit dans le message de news:
problèmes. (J'utilise les auto_ptr dans l'interface de la queue de messages entre les threads, justement pour dire à l'utilisateur de ne plus toucher à l'objet une fois qu'il l'a passé à l'autre thread. Même si l'implémentation de la queue se base sur std::deque, ce qui m'impose un passage par des pointeurs bruts.)
As-tu un exemple, même simple, pour illustrer ce mécanisme ? Perso, j'utilise des mécanismes de synchronisation, mais peut être que ta méthode est plus simple...
-- -Stan
<kanze@gabi-soft.fr> a écrit dans le message de news:
1125042187.793176.166170@g44g2000cwa.googlegroups.com...
problèmes. (J'utilise les auto_ptr dans l'interface de la queue
de messages entre les threads, justement pour dire à
l'utilisateur de ne plus toucher à l'objet une fois qu'il l'a
passé à l'autre thread. Même si l'implémentation de la queue se
base sur std::deque, ce qui m'impose un passage par des
pointeurs bruts.)
As-tu un exemple, même simple, pour illustrer ce mécanisme ?
Perso, j'utilise des mécanismes de synchronisation, mais peut être
que ta méthode est plus simple...
problèmes. (J'utilise les auto_ptr dans l'interface de la queue de messages entre les threads, justement pour dire à l'utilisateur de ne plus toucher à l'objet une fois qu'il l'a passé à l'autre thread. Même si l'implémentation de la queue se base sur std::deque, ce qui m'impose un passage par des pointeurs bruts.)
As-tu un exemple, même simple, pour illustrer ce mécanisme ? Perso, j'utilise des mécanismes de synchronisation, mais peut être que ta méthode est plus simple...
-- -Stan
Leroux Philippe
wrote:
Fabien LE LEZ wrote:
On Thu, 25 Aug 2005 16:35:19 +0200, "leroux_philippe at yahoo.fr" <"leroux_philippe at yahoo.fr">:
(au passage c'est la première fois que j'utilise aut_ptr)
M'étonne pas. En pratique, c'est rarement utile, ce machin. AMHA tu devrais plutôt t'intéresser à boost::shared_ptr<>, beaucoup plus utilisé.
Ta réponse me laisse perplexe, j'ai pas tout compris.
Curieux. Moi, j'utilise auto_ptr beaucoup plus souvent que les shared_ptr. Typiquement, si je ne veux pas de copie profond, c'est que l'objet est immutable. Et si l'objet est immutable, la plupart du temps, je m'arrange à le déclarer quelque part avec une durée de vie statique. C'est encore plus vrai dans un
Pourrais tu m'expliquer ce que tu entends par 'copie profond' ?
environnement multi-threaded, parce que partager des objets mutables entre plusieurs threads implique tout genre de problèmes. (J'utilise les auto_ptr dans l'interface de la queue de messages entre les threads, justement pour dire à l'utilisateur de ne plus toucher à l'objet une fois qu'il l'a passé à l'autre thread. Même si l'implémentation de la queue se base sur std::deque, ce qui m'impose un passage par des pointeurs bruts.)
Mon problème est différent, il est mono-thread, mais c'est un GUI composé de fenêtres partageant des données communes. Mon objectif est de ne pas dupliqué la donnée de base (BTest) qui est peut être très longue à construire et peut être gourmand en mémoire (il peut exister, en théorie, une infinité de BTest).
Etat actuel : Je construis le BTest son contenue sera constant pendant toute sa vie, le pointeur est passé à une class d'affichage A. Une fois que A a le pointeur BTest c'est A qui détruit BTest (BTest finie toujours dans un A, c'est sa raison d'être).
Par la suite j'ai ajouté une class G (Graphique) pour afficher un graphique sur des élements de BTest.
L'objet A demande la création de G en fournissant une référence constante sur BTest. Si A se détruit, il demande à G de se détruire, puis détruit BTest. Donc G ne possède jamais de référence invalide.
Mon problème c'est que maintenant la durée de vie de G ne doit plus dépendre de A. Si A se ferme, G doit continuer a exister et donc BTest. Si G se ferme, A doit continuer a exister et donc BTest. Si A et G sont fermés BTest ne doit plus exister.
(Et là la référence marche plus, donc j'ai pensé à auto_ptr.)
Donc le BTest sera partagé entre plusieurs ReTest (au minimum 2, donc le premier ne vivra pas plus de 1 seconde) puis un A (C'est G qui possède le ReTest). J'imagine que G (qui est dans une bibliothèque tierce) pourra s'amuser à faire autant de copie qu'il souhaite de ReTest, mais je voudrais que BTest soit toujours le même.
Je me trompe peut être mais le but de auto_ptr et bien de détruire BTest quand plus personne n'y fera référence ?
La question ici, c'est qu'est-ce qu'il veut comme sémantique. S'il veut qu'un BTest soit partagé entre plusieurs ReTest,
Oui c'est ca.
shared_ptr est une solution. Si en revanche il veut que chaque
:(
instance de ReTest ait sa propre instance de BTest (ce qui est fort probable is BTest n'est pas constante), c'est bien auto_ptr qu'il lui faut. Seulement alors, évidemment, quand il fait la copie, il faut qu'il s'arrange pour copier le BTest aussi :
Je ne dois vraiment pas avoir saisie le rôle de auto_ptr !
QwtCopy* ReTest::copy() const { return new ReTest( std::auto_ptr< BTest >( new BTest(*t) ) ) ; }
Le fait que le compilateur émet une erreur est juste -- il a bien oublié quelque chose.
Et là je duplique t et le BTest qu'il contient ?
Je ne peux pas dupliquer seulement t et que BTest soit toujours le même ?
Pour l'instant je n'utilise pas boost, si une solution existe avec la STL...
kanze@gabi-soft.fr wrote:
Fabien LE LEZ wrote:
On Thu, 25 Aug 2005 16:35:19 +0200, "leroux_philippe at yahoo.fr"
<"leroux_philippe at yahoo.fr">:
(au passage c'est la première fois que j'utilise
aut_ptr)
M'étonne pas. En pratique, c'est rarement utile, ce machin.
AMHA tu devrais plutôt t'intéresser à boost::shared_ptr<>,
beaucoup plus utilisé.
Ta réponse me laisse perplexe, j'ai pas tout compris.
Curieux. Moi, j'utilise auto_ptr beaucoup plus souvent que les
shared_ptr. Typiquement, si je ne veux pas de copie profond,
c'est que l'objet est immutable. Et si l'objet est immutable, la
plupart du temps, je m'arrange à le déclarer quelque part avec
une durée de vie statique. C'est encore plus vrai dans un
Pourrais tu m'expliquer ce que tu entends par 'copie profond' ?
environnement multi-threaded, parce que partager des objets
mutables entre plusieurs threads implique tout genre de
problèmes. (J'utilise les auto_ptr dans l'interface de la queue
de messages entre les threads, justement pour dire à
l'utilisateur de ne plus toucher à l'objet une fois qu'il l'a
passé à l'autre thread. Même si l'implémentation de la queue se
base sur std::deque, ce qui m'impose un passage par des
pointeurs bruts.)
Mon problème est différent, il est mono-thread, mais c'est un
GUI composé de fenêtres partageant des données communes.
Mon objectif est de ne pas dupliqué la donnée de base (BTest)
qui est peut être très longue à construire et peut être gourmand en
mémoire (il peut exister, en théorie, une infinité de BTest).
Etat actuel :
Je construis le BTest son contenue sera constant pendant toute sa vie,
le pointeur est passé à une class d'affichage A.
Une fois que A a le pointeur BTest c'est A qui détruit BTest (BTest
finie toujours dans un A, c'est sa raison d'être).
Par la suite j'ai ajouté une class G (Graphique) pour afficher un
graphique sur des élements de BTest.
L'objet A demande la création de G en fournissant une référence
constante sur BTest.
Si A se détruit, il demande à G de se détruire, puis détruit BTest.
Donc G ne possède jamais de référence invalide.
Mon problème c'est que maintenant la durée de vie de G ne doit plus
dépendre de A.
Si A se ferme, G doit continuer a exister et donc BTest.
Si G se ferme, A doit continuer a exister et donc BTest.
Si A et G sont fermés BTest ne doit plus exister.
(Et là la référence marche plus, donc j'ai pensé à auto_ptr.)
Donc le BTest sera partagé entre plusieurs ReTest (au minimum 2, donc
le premier ne vivra pas plus de 1 seconde) puis un A (C'est G qui
possède le ReTest). J'imagine que G (qui est dans une bibliothèque
tierce) pourra s'amuser à faire autant de copie qu'il souhaite de
ReTest, mais je voudrais que BTest soit toujours le même.
Je me trompe peut être mais le but de auto_ptr et bien de détruire
BTest quand plus personne n'y fera référence ?
La question ici, c'est qu'est-ce qu'il veut comme sémantique.
S'il veut qu'un BTest soit partagé entre plusieurs ReTest,
Oui c'est ca.
shared_ptr est une solution. Si en revanche il veut que chaque
:(
instance de ReTest ait sa propre instance de BTest (ce qui est
fort probable is BTest n'est pas constante), c'est bien auto_ptr
qu'il lui faut. Seulement alors, évidemment, quand il fait la
copie, il faut qu'il s'arrange pour copier le BTest aussi :
Je ne dois vraiment pas avoir saisie le rôle de auto_ptr !
QwtCopy*
ReTest::copy() const
{
return new ReTest(
std::auto_ptr< BTest >( new BTest(*t) ) ) ;
}
Le fait que le compilateur émet une erreur est juste -- il a
bien oublié quelque chose.
Et là je duplique t et le BTest qu'il contient ?
Je ne peux pas dupliquer seulement t et que BTest soit toujours le même ?
Pour l'instant je n'utilise pas boost, si une solution existe avec la STL...
On Thu, 25 Aug 2005 16:35:19 +0200, "leroux_philippe at yahoo.fr" <"leroux_philippe at yahoo.fr">:
(au passage c'est la première fois que j'utilise aut_ptr)
M'étonne pas. En pratique, c'est rarement utile, ce machin. AMHA tu devrais plutôt t'intéresser à boost::shared_ptr<>, beaucoup plus utilisé.
Ta réponse me laisse perplexe, j'ai pas tout compris.
Curieux. Moi, j'utilise auto_ptr beaucoup plus souvent que les shared_ptr. Typiquement, si je ne veux pas de copie profond, c'est que l'objet est immutable. Et si l'objet est immutable, la plupart du temps, je m'arrange à le déclarer quelque part avec une durée de vie statique. C'est encore plus vrai dans un
Pourrais tu m'expliquer ce que tu entends par 'copie profond' ?
environnement multi-threaded, parce que partager des objets mutables entre plusieurs threads implique tout genre de problèmes. (J'utilise les auto_ptr dans l'interface de la queue de messages entre les threads, justement pour dire à l'utilisateur de ne plus toucher à l'objet une fois qu'il l'a passé à l'autre thread. Même si l'implémentation de la queue se base sur std::deque, ce qui m'impose un passage par des pointeurs bruts.)
Mon problème est différent, il est mono-thread, mais c'est un GUI composé de fenêtres partageant des données communes. Mon objectif est de ne pas dupliqué la donnée de base (BTest) qui est peut être très longue à construire et peut être gourmand en mémoire (il peut exister, en théorie, une infinité de BTest).
Etat actuel : Je construis le BTest son contenue sera constant pendant toute sa vie, le pointeur est passé à une class d'affichage A. Une fois que A a le pointeur BTest c'est A qui détruit BTest (BTest finie toujours dans un A, c'est sa raison d'être).
Par la suite j'ai ajouté une class G (Graphique) pour afficher un graphique sur des élements de BTest.
L'objet A demande la création de G en fournissant une référence constante sur BTest. Si A se détruit, il demande à G de se détruire, puis détruit BTest. Donc G ne possède jamais de référence invalide.
Mon problème c'est que maintenant la durée de vie de G ne doit plus dépendre de A. Si A se ferme, G doit continuer a exister et donc BTest. Si G se ferme, A doit continuer a exister et donc BTest. Si A et G sont fermés BTest ne doit plus exister.
(Et là la référence marche plus, donc j'ai pensé à auto_ptr.)
Donc le BTest sera partagé entre plusieurs ReTest (au minimum 2, donc le premier ne vivra pas plus de 1 seconde) puis un A (C'est G qui possède le ReTest). J'imagine que G (qui est dans une bibliothèque tierce) pourra s'amuser à faire autant de copie qu'il souhaite de ReTest, mais je voudrais que BTest soit toujours le même.
Je me trompe peut être mais le but de auto_ptr et bien de détruire BTest quand plus personne n'y fera référence ?
La question ici, c'est qu'est-ce qu'il veut comme sémantique. S'il veut qu'un BTest soit partagé entre plusieurs ReTest,
Oui c'est ca.
shared_ptr est une solution. Si en revanche il veut que chaque
:(
instance de ReTest ait sa propre instance de BTest (ce qui est fort probable is BTest n'est pas constante), c'est bien auto_ptr qu'il lui faut. Seulement alors, évidemment, quand il fait la copie, il faut qu'il s'arrange pour copier le BTest aussi :
Je ne dois vraiment pas avoir saisie le rôle de auto_ptr !
QwtCopy* ReTest::copy() const { return new ReTest( std::auto_ptr< BTest >( new BTest(*t) ) ) ; }
Le fait que le compilateur émet une erreur est juste -- il a bien oublié quelque chose.
Et là je duplique t et le BTest qu'il contient ?
Je ne peux pas dupliquer seulement t et que BTest soit toujours le même ?
Pour l'instant je n'utilise pas boost, si une solution existe avec la STL...
Fabien LE LEZ
On Mon, 29 Aug 2005 12:34:38 +0200, Leroux Philippe :
Si A se ferme, G doit continuer a exister et donc BTest. Si G se ferme, A doit continuer a exister et donc BTest. Si A et G sont fermés BTest ne doit plus exister.
C'est bien ce que je disais : tu veux un pointeur partagé entre plusieurs objets indépendants. Donc, shared_ptr.
Je me trompe peut être mais le but de auto_ptr et bien de détruire BTest quand plus personne n'y fera référence ?
Non, auto_ptr s'occupe de détruire BTest quand le dernier objet à l'avoir eu en main se "termine".
auto_ptr : A dit à G "Tiens, je te file ce BTest, tu t'en occupes, je ne veux plus en entendre parler." shared_ptr : A dit à G "Tiens, je partage ce BTest avec toi, et le dernier à partir éteint la lumière."
On Mon, 29 Aug 2005 12:34:38 +0200, Leroux Philippe
<leroux_philippe@yahoo.fr>:
Si A se ferme, G doit continuer a exister et donc BTest.
Si G se ferme, A doit continuer a exister et donc BTest.
Si A et G sont fermés BTest ne doit plus exister.
C'est bien ce que je disais : tu veux un pointeur partagé entre
plusieurs objets indépendants. Donc, shared_ptr.
Je me trompe peut être mais le but de auto_ptr et bien de détruire
BTest quand plus personne n'y fera référence ?
Non, auto_ptr s'occupe de détruire BTest quand le dernier objet à
l'avoir eu en main se "termine".
auto_ptr : A dit à G "Tiens, je te file ce BTest, tu t'en occupes, je
ne veux plus en entendre parler."
shared_ptr : A dit à G "Tiens, je partage ce BTest avec toi, et le
dernier à partir éteint la lumière."
On Mon, 29 Aug 2005 12:34:38 +0200, Leroux Philippe :
Si A se ferme, G doit continuer a exister et donc BTest. Si G se ferme, A doit continuer a exister et donc BTest. Si A et G sont fermés BTest ne doit plus exister.
C'est bien ce que je disais : tu veux un pointeur partagé entre plusieurs objets indépendants. Donc, shared_ptr.
Je me trompe peut être mais le but de auto_ptr et bien de détruire BTest quand plus personne n'y fera référence ?
Non, auto_ptr s'occupe de détruire BTest quand le dernier objet à l'avoir eu en main se "termine".
auto_ptr : A dit à G "Tiens, je te file ce BTest, tu t'en occupes, je ne veux plus en entendre parler." shared_ptr : A dit à G "Tiens, je partage ce BTest avec toi, et le dernier à partir éteint la lumière."
stephane_www
Fabien LE LEZ wrote:
On Mon, 29 Aug 2005 12:34:38 +0200, Leroux Philippe :
Si A se ferme, G doit continuer a exister et donc BTest. Si G se ferme, A doit continuer a exister et donc BTest. Si A et G sont fermés BTest ne doit plus exister.
C'est bien ce que je disais : tu veux un pointeur partagé entre plusieurs objets indépendants. Donc, shared_ptr.
Je me trompe peut être mais le but de auto_ptr et bien de détruire BTest quand plus personne n'y fera référence ?
Non, auto_ptr s'occupe de détruire BTest quand le dernier objet à l'avoir eu en main se "termine".
auto_ptr : A dit à G "Tiens, je te file ce BTest, tu t'en occupes, je ne veux plus en entendre parler." shared_ptr : A dit à G "Tiens, je partage ce BTest avec toi, et le dernier à partir éteint la lumière."
La nuance est subtile.
Je vais voir pour boost...
Merci.
Fabien LE LEZ wrote:
On Mon, 29 Aug 2005 12:34:38 +0200, Leroux Philippe
<leroux_philippe@yahoo.fr>:
Si A se ferme, G doit continuer a exister et donc BTest.
Si G se ferme, A doit continuer a exister et donc BTest.
Si A et G sont fermés BTest ne doit plus exister.
C'est bien ce que je disais : tu veux un pointeur partagé entre
plusieurs objets indépendants. Donc, shared_ptr.
Je me trompe peut être mais le but de auto_ptr et bien de détruire
BTest quand plus personne n'y fera référence ?
Non, auto_ptr s'occupe de détruire BTest quand le dernier objet à
l'avoir eu en main se "termine".
auto_ptr : A dit à G "Tiens, je te file ce BTest, tu t'en occupes, je
ne veux plus en entendre parler."
shared_ptr : A dit à G "Tiens, je partage ce BTest avec toi, et le
dernier à partir éteint la lumière."
On Mon, 29 Aug 2005 12:34:38 +0200, Leroux Philippe :
Si A se ferme, G doit continuer a exister et donc BTest. Si G se ferme, A doit continuer a exister et donc BTest. Si A et G sont fermés BTest ne doit plus exister.
C'est bien ce que je disais : tu veux un pointeur partagé entre plusieurs objets indépendants. Donc, shared_ptr.
Je me trompe peut être mais le but de auto_ptr et bien de détruire BTest quand plus personne n'y fera référence ?
Non, auto_ptr s'occupe de détruire BTest quand le dernier objet à l'avoir eu en main se "termine".
auto_ptr : A dit à G "Tiens, je te file ce BTest, tu t'en occupes, je ne veux plus en entendre parler." shared_ptr : A dit à G "Tiens, je partage ce BTest avec toi, et le dernier à partir éteint la lumière."
problèmes. (J'utilise les auto_ptr dans l'interface de la queue de messages entre les threads, justement pour dire à l'utilisateur de ne plus toucher à l'objet une fois qu'il l'a passé à l'autre thread. Même si l'implémentation de la queue se base sur std::deque, ce qui m'impose un passage par des pointeurs bruts.)
As-tu un exemple, même simple, pour illustrer ce mécanisme ? Perso, j'utilise des mécanismes de synchronisation, mais peut être que ta méthode est plus simple...
Elle ne s'applique pas partout, mais la règle de base, c'est que tout objet appartient à un seul thread à la fois. Typiquement, si l'objet offre une service complexe, il appartient à un un seul thread en permanence, et les objets qu'on passe entre les threads sont des requêtes et des résultats. Mais il m'arrive de m'en servir aussi pour des objets avec un comportement plus simple, où c'est l'objet même qu'on passe au thread de service, et non simplement une requête.
Donc, par exemple, on pourrait imaginer une connection avec une base de données. Dans ce cas-là, il est probable que ce soit le thread serveur qui gère la connection même, et que les autres threads construisent des requêtes, qu'ils envoient dans une queue. Le thread de service attend sur la queue, en extrait les requêtes une à une et les exécutent. En somme, son code ressemble :
Selon les cas, la requête peut contenir une queue où la réponse sera envoyer, ou un callback -- cette dernière solution permet, par exemple, de poster la réponse comme évenemment dans le thread du GUI.
L'importance, c'est qu'une fois envoyer au thread de service, l'objet requête n'appartient plus au thread client, qui n'a plus droit d'y toucher. De la même façon, une fois la réponse envoyée, le thread de service n'a plus le droit d'y toucher.
Note que si nécessaire, on peut très bien créer plusieurs threads qui écoutent sur la même queue (chacun avec sa propre connection), de façon à pouvoir exécuter plusieurs requêtes en parallel.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Stan wrote:
<kanze@gabi-soft.fr> a écrit dans le message de news:
1125042187.793176.166170@g44g2000cwa.googlegroups.com...
problèmes. (J'utilise les auto_ptr dans l'interface de la
queue de messages entre les threads, justement pour dire à
l'utilisateur de ne plus toucher à l'objet une fois qu'il l'a
passé à l'autre thread. Même si l'implémentation de la queue
se base sur std::deque, ce qui m'impose un passage par des
pointeurs bruts.)
As-tu un exemple, même simple, pour illustrer ce mécanisme ?
Perso, j'utilise des mécanismes de synchronisation, mais peut
être que ta méthode est plus simple...
Elle ne s'applique pas partout, mais la règle de base, c'est que
tout objet appartient à un seul thread à la fois. Typiquement,
si l'objet offre une service complexe, il appartient à un un
seul thread en permanence, et les objets qu'on passe entre les
threads sont des requêtes et des résultats. Mais il m'arrive de
m'en servir aussi pour des objets avec un comportement plus
simple, où c'est l'objet même qu'on passe au thread de service,
et non simplement une requête.
Donc, par exemple, on pourrait imaginer une connection avec une
base de données. Dans ce cas-là, il est probable que ce soit le
thread serveur qui gère la connection même, et que les autres
threads construisent des requêtes, qu'ils envoient dans une
queue. Le thread de service attend sur la queue, en extrait les
requêtes une à une et les exécutent. En somme, son code
ressemble :
Selon les cas, la requête peut contenir une queue où la réponse
sera envoyer, ou un callback -- cette dernière solution permet,
par exemple, de poster la réponse comme évenemment dans le
thread du GUI.
L'importance, c'est qu'une fois envoyer au thread de service,
l'objet requête n'appartient plus au thread client, qui n'a plus
droit d'y toucher. De la même façon, une fois la réponse
envoyée, le thread de service n'a plus le droit d'y toucher.
Note que si nécessaire, on peut très bien créer plusieurs
threads qui écoutent sur la même queue (chacun avec sa propre
connection), de façon à pouvoir exécuter plusieurs requêtes en
parallel.
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
problèmes. (J'utilise les auto_ptr dans l'interface de la queue de messages entre les threads, justement pour dire à l'utilisateur de ne plus toucher à l'objet une fois qu'il l'a passé à l'autre thread. Même si l'implémentation de la queue se base sur std::deque, ce qui m'impose un passage par des pointeurs bruts.)
As-tu un exemple, même simple, pour illustrer ce mécanisme ? Perso, j'utilise des mécanismes de synchronisation, mais peut être que ta méthode est plus simple...
Elle ne s'applique pas partout, mais la règle de base, c'est que tout objet appartient à un seul thread à la fois. Typiquement, si l'objet offre une service complexe, il appartient à un un seul thread en permanence, et les objets qu'on passe entre les threads sont des requêtes et des résultats. Mais il m'arrive de m'en servir aussi pour des objets avec un comportement plus simple, où c'est l'objet même qu'on passe au thread de service, et non simplement une requête.
Donc, par exemple, on pourrait imaginer une connection avec une base de données. Dans ce cas-là, il est probable que ce soit le thread serveur qui gère la connection même, et que les autres threads construisent des requêtes, qu'ils envoient dans une queue. Le thread de service attend sur la queue, en extrait les requêtes une à une et les exécutent. En somme, son code ressemble :
Selon les cas, la requête peut contenir une queue où la réponse sera envoyer, ou un callback -- cette dernière solution permet, par exemple, de poster la réponse comme évenemment dans le thread du GUI.
L'importance, c'est qu'une fois envoyer au thread de service, l'objet requête n'appartient plus au thread client, qui n'a plus droit d'y toucher. De la même façon, une fois la réponse envoyée, le thread de service n'a plus le droit d'y toucher.
Note que si nécessaire, on peut très bien créer plusieurs threads qui écoutent sur la même queue (chacun avec sa propre connection), de façon à pouvoir exécuter plusieurs requêtes en parallel.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
Stan wrote:
a écrit dans le message de news:
problèmes. (J'utilise les auto_ptr dans l'interface de la queue de messages entre les threads, justement pour dire à l'utilisateur de ne plus toucher à l'objet une fois qu'il l'a passé à l'autre thread. Même si l'implémentation de la queue se base sur std::deque, ce qui m'impose un passage par des pointeurs bruts.)
As-tu un exemple, même simple, pour illustrer ce mécanisme ? Perso, j'utilise des mécanismes de synchronisation, mais peut être que ta méthode est plus simple...
Elle ne s'applique pas partout, mais la règle de base, c'est que tout objet appartient à un seul thread à la fois. Typiquement, si l'objet offre une service complexe, il appartient à un un seul thread en permanence, et les objets qu'on passe entre les threads sont des requêtes et des résultats. Mais il m'arrive de m'en servir aussi pour des objets avec un comportement plus simple, où c'est l'objet même qu'on passe au thread de service, et non simplement une requête.
Donc, par exemple, on pourrait imaginer une connection avec une base de données. Dans ce cas-là, il est probable que ce soit le thread serveur qui gère la connection même, et que les autres threads construisent des requêtes, qu'ils envoient dans une queue. Le thread de service attend sur la queue, en extrait les requêtes une à une et les exécutent. En somme, son code ressemble :
Selon les cas, la requête peut contenir une queue où la réponse sera envoyer, ou un callback -- cette dernière solution permet, par exemple, de poster la réponse comme évenemment dans le thread du GUI.
L'importance, c'est qu'une fois envoyer au thread de service, l'objet requête n'appartient plus au thread client, qui n'a plus droit d'y toucher. De la même façon, une fois la réponse envoyée, le thread de service n'a plus le droit d'y toucher.
Note que si nécessaire, on peut très bien créer plusieurs threads qui écoutent sur la même queue (chacun avec sa propre connection), de façon à pouvoir exécuter plusieurs requêtes en parallel.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Stan wrote:
<kanze@gabi-soft.fr> a écrit dans le message de news:
1125042187.793176.166170@g44g2000cwa.googlegroups.com...
problèmes. (J'utilise les auto_ptr dans l'interface de la
queue de messages entre les threads, justement pour dire à
l'utilisateur de ne plus toucher à l'objet une fois qu'il l'a
passé à l'autre thread. Même si l'implémentation de la queue
se base sur std::deque, ce qui m'impose un passage par des
pointeurs bruts.)
As-tu un exemple, même simple, pour illustrer ce mécanisme ?
Perso, j'utilise des mécanismes de synchronisation, mais peut
être que ta méthode est plus simple...
Elle ne s'applique pas partout, mais la règle de base, c'est que
tout objet appartient à un seul thread à la fois. Typiquement,
si l'objet offre une service complexe, il appartient à un un
seul thread en permanence, et les objets qu'on passe entre les
threads sont des requêtes et des résultats. Mais il m'arrive de
m'en servir aussi pour des objets avec un comportement plus
simple, où c'est l'objet même qu'on passe au thread de service,
et non simplement une requête.
Donc, par exemple, on pourrait imaginer une connection avec une
base de données. Dans ce cas-là, il est probable que ce soit le
thread serveur qui gère la connection même, et que les autres
threads construisent des requêtes, qu'ils envoient dans une
queue. Le thread de service attend sur la queue, en extrait les
requêtes une à une et les exécutent. En somme, son code
ressemble :
Selon les cas, la requête peut contenir une queue où la réponse
sera envoyer, ou un callback -- cette dernière solution permet,
par exemple, de poster la réponse comme évenemment dans le
thread du GUI.
L'importance, c'est qu'une fois envoyer au thread de service,
l'objet requête n'appartient plus au thread client, qui n'a plus
droit d'y toucher. De la même façon, une fois la réponse
envoyée, le thread de service n'a plus le droit d'y toucher.
Note que si nécessaire, on peut très bien créer plusieurs
threads qui écoutent sur la même queue (chacun avec sa propre
connection), de façon à pouvoir exécuter plusieurs requêtes en
parallel.
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
problèmes. (J'utilise les auto_ptr dans l'interface de la queue de messages entre les threads, justement pour dire à l'utilisateur de ne plus toucher à l'objet une fois qu'il l'a passé à l'autre thread. Même si l'implémentation de la queue se base sur std::deque, ce qui m'impose un passage par des pointeurs bruts.)
As-tu un exemple, même simple, pour illustrer ce mécanisme ? Perso, j'utilise des mécanismes de synchronisation, mais peut être que ta méthode est plus simple...
Elle ne s'applique pas partout, mais la règle de base, c'est que tout objet appartient à un seul thread à la fois. Typiquement, si l'objet offre une service complexe, il appartient à un un seul thread en permanence, et les objets qu'on passe entre les threads sont des requêtes et des résultats. Mais il m'arrive de m'en servir aussi pour des objets avec un comportement plus simple, où c'est l'objet même qu'on passe au thread de service, et non simplement une requête.
Donc, par exemple, on pourrait imaginer une connection avec une base de données. Dans ce cas-là, il est probable que ce soit le thread serveur qui gère la connection même, et que les autres threads construisent des requêtes, qu'ils envoient dans une queue. Le thread de service attend sur la queue, en extrait les requêtes une à une et les exécutent. En somme, son code ressemble :
Selon les cas, la requête peut contenir une queue où la réponse sera envoyer, ou un callback -- cette dernière solution permet, par exemple, de poster la réponse comme évenemment dans le thread du GUI.
L'importance, c'est qu'une fois envoyer au thread de service, l'objet requête n'appartient plus au thread client, qui n'a plus droit d'y toucher. De la même façon, une fois la réponse envoyée, le thread de service n'a plus le droit d'y toucher.
Note que si nécessaire, on peut très bien créer plusieurs threads qui écoutent sur la même queue (chacun avec sa propre connection), de façon à pouvoir exécuter plusieurs requêtes en parallel.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
