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...
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 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."
Leroux Philippe wrote:wrote:Fabien LE LEZ wrote:
[]
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).
Et qui est immutable ? S'il n'est pas immutable, que doit être
la sémantique lorsqu'un odes objets du GUI le modifie ?
BTest ne contient que des données, n'est-ce pas ? (Sinon, le
fait qu'il soit immutable me semble curieux.) Alors, tout ce
qu'il te faut, c'est un glaneur de cellules.
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 ?
Pas du tout. Le but de auto_ptr, c'est de garantir qu'à un
moment donné, un auto_ptr, et un seul, a commande de l'objet,
peut y accéder, et en est résonsable de sa destruction. Quand tu
« copies » un auto_ptr, la commande passe du pointeur source au
pointeur cible ; on ne peut plus accéder à l'objet qu'à travers
le pointeur cible.
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
:(
Pourquoi :(. La sémantique que tu décris n'est pas la plus
[]
C'est ce que fait un pointeur brut. Les seuls problèmes, ce
sont la durée de vie de BTest, et la gestion de la mémoire. Si
BTest est immutable (et la plupart de temps, même s'il n'est pas
mutable), la durée de vie n'a pas beaucoup d'importance ; en
revanche, avec le C++ standard, c'est au programmeur de
s'emmerder avec la gestion de la mémoire. Au moins qu'on utilise
un glaneur de cellules.Pour l'instant je n'utilise pas boost, si une solution existe
avec la STL...
Une solution pour l'interface graphique existe-t-elle avec la
STL... ?
En fait, il faut prèsque toujours aller au délà de la STL dans
un programme réel. Alors, pourquoi accepter X ou Windows, mais
non Boost ou le glaneur de cellules de Boehm. Dans la pratique,
l'un ou l'autre est plus portable que le C++ « standard ».
Leroux Philippe wrote:
kanze@gabi-soft.fr wrote:
Fabien LE LEZ wrote:
[]
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).
Et qui est immutable ? S'il n'est pas immutable, que doit être
la sémantique lorsqu'un odes objets du GUI le modifie ?
BTest ne contient que des données, n'est-ce pas ? (Sinon, le
fait qu'il soit immutable me semble curieux.) Alors, tout ce
qu'il te faut, c'est un glaneur de cellules.
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 ?
Pas du tout. Le but de auto_ptr, c'est de garantir qu'à un
moment donné, un auto_ptr, et un seul, a commande de l'objet,
peut y accéder, et en est résonsable de sa destruction. Quand tu
« copies » un auto_ptr, la commande passe du pointeur source au
pointeur cible ; on ne peut plus accéder à l'objet qu'à travers
le pointeur cible.
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
:(
Pourquoi :(. La sémantique que tu décris n'est pas la plus
[]
C'est ce que fait un pointeur brut. Les seuls problèmes, ce
sont la durée de vie de BTest, et la gestion de la mémoire. Si
BTest est immutable (et la plupart de temps, même s'il n'est pas
mutable), la durée de vie n'a pas beaucoup d'importance ; en
revanche, avec le C++ standard, c'est au programmeur de
s'emmerder avec la gestion de la mémoire. Au moins qu'on utilise
un glaneur de cellules.
Pour l'instant je n'utilise pas boost, si une solution existe
avec la STL...
Une solution pour l'interface graphique existe-t-elle avec la
STL... ?
En fait, il faut prèsque toujours aller au délà de la STL dans
un programme réel. Alors, pourquoi accepter X ou Windows, mais
non Boost ou le glaneur de cellules de Boehm. Dans la pratique,
l'un ou l'autre est plus portable que le C++ « standard ».
Leroux Philippe wrote:wrote:Fabien LE LEZ wrote:
[]
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).
Et qui est immutable ? S'il n'est pas immutable, que doit être
la sémantique lorsqu'un odes objets du GUI le modifie ?
BTest ne contient que des données, n'est-ce pas ? (Sinon, le
fait qu'il soit immutable me semble curieux.) Alors, tout ce
qu'il te faut, c'est un glaneur de cellules.
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 ?
Pas du tout. Le but de auto_ptr, c'est de garantir qu'à un
moment donné, un auto_ptr, et un seul, a commande de l'objet,
peut y accéder, et en est résonsable de sa destruction. Quand tu
« copies » un auto_ptr, la commande passe du pointeur source au
pointeur cible ; on ne peut plus accéder à l'objet qu'à travers
le pointeur cible.
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
:(
Pourquoi :(. La sémantique que tu décris n'est pas la plus
[]
C'est ce que fait un pointeur brut. Les seuls problèmes, ce
sont la durée de vie de BTest, et la gestion de la mémoire. Si
BTest est immutable (et la plupart de temps, même s'il n'est pas
mutable), la durée de vie n'a pas beaucoup d'importance ; en
revanche, avec le C++ standard, c'est au programmeur de
s'emmerder avec la gestion de la mémoire. Au moins qu'on utilise
un glaneur de cellules.Pour l'instant je n'utilise pas boost, si une solution existe
avec la STL...
Une solution pour l'interface graphique existe-t-elle avec la
STL... ?
En fait, il faut prèsque toujours aller au délà de la STL dans
un programme réel. Alors, pourquoi accepter X ou Windows, mais
non Boost ou le glaneur de cellules de Boehm. Dans la pratique,
l'un ou l'autre est plus portable que le C++ « standard ».
James Kanze wrote:Leroux Philippe wrote:wrote:Fabien LE LEZ wrote:
[]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).
Et qui est immutable ? S'il n'est pas immutable, que doit être
la sémantique lorsqu'un odes objets du GUI le modifie ?
Oui, il est immutable.
[]BTest ne contient que des données, n'est-ce pas ? (Sinon,
le fait qu'il soit immutable me semble curieux.) Alors,
tout ce qu'il te faut, c'est un glaneur de cellules.
BTest sert à manipuler un vector. C'est le vector que je ne
veux pas modifier/dupliquer.
Pour l'instant je n'utilise pas boost, si une solution existe
avec la STL...
Une solution pour l'interface graphique existe-t-elle avec la
STL... ?
En fait, il faut prèsque toujours aller au délà de la STL
dans un programme réel. Alors, pourquoi accepter X ou
Windows, mais non Boost ou le glaneur de cellules de
Boehm. Dans la pratique, l'un ou l'autre est plus portable
que le C++ « standard ».
La raison est extrêmement simple :
On écrit un soft qui a pour cible deux machines bien définies
et strictements identiques, On a installé exactement la même
chose pour le dev.
Une des contraintes est de ne pas toucher à la config, la STL
et X sont là.
On a déjà fait une exception en ajoutant une lib non présente
en standard et plus grave en option non plus.
James Kanze wrote:
Leroux Philippe wrote:
kanze@gabi-soft.fr wrote:
Fabien LE LEZ wrote:
[]
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).
Et qui est immutable ? S'il n'est pas immutable, que doit être
la sémantique lorsqu'un odes objets du GUI le modifie ?
Oui, il est immutable.
[]
BTest ne contient que des données, n'est-ce pas ? (Sinon,
le fait qu'il soit immutable me semble curieux.) Alors,
tout ce qu'il te faut, c'est un glaneur de cellules.
BTest sert à manipuler un vector. C'est le vector que je ne
veux pas modifier/dupliquer.
Pour l'instant je n'utilise pas boost, si une solution existe
avec la STL...
Une solution pour l'interface graphique existe-t-elle avec la
STL... ?
En fait, il faut prèsque toujours aller au délà de la STL
dans un programme réel. Alors, pourquoi accepter X ou
Windows, mais non Boost ou le glaneur de cellules de
Boehm. Dans la pratique, l'un ou l'autre est plus portable
que le C++ « standard ».
La raison est extrêmement simple :
On écrit un soft qui a pour cible deux machines bien définies
et strictements identiques, On a installé exactement la même
chose pour le dev.
Une des contraintes est de ne pas toucher à la config, la STL
et X sont là.
On a déjà fait une exception en ajoutant une lib non présente
en standard et plus grave en option non plus.
James Kanze wrote:Leroux Philippe wrote:wrote:Fabien LE LEZ wrote:
[]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).
Et qui est immutable ? S'il n'est pas immutable, que doit être
la sémantique lorsqu'un odes objets du GUI le modifie ?
Oui, il est immutable.
[]BTest ne contient que des données, n'est-ce pas ? (Sinon,
le fait qu'il soit immutable me semble curieux.) Alors,
tout ce qu'il te faut, c'est un glaneur de cellules.
BTest sert à manipuler un vector. C'est le vector que je ne
veux pas modifier/dupliquer.
Pour l'instant je n'utilise pas boost, si une solution existe
avec la STL...
Une solution pour l'interface graphique existe-t-elle avec la
STL... ?
En fait, il faut prèsque toujours aller au délà de la STL
dans un programme réel. Alors, pourquoi accepter X ou
Windows, mais non Boost ou le glaneur de cellules de
Boehm. Dans la pratique, l'un ou l'autre est plus portable
que le C++ « standard ».
La raison est extrêmement simple :
On écrit un soft qui a pour cible deux machines bien définies
et strictements identiques, On a installé exactement la même
chose pour le dev.
Une des contraintes est de ne pas toucher à la config, la STL
et X sont là.
On a déjà fait une exception en ajoutant une lib non présente
en standard et plus grave en option non plus.
Je ne suis pas sûr si j'ai compris. Il faut bien une machine
image de la production pour les tests. Mais on ne peut pas trop
y développer, étant donné que les machines de la production
n'ont pas de compilateur.Une des contraintes est de ne pas toucher à la config, la STL
et X sont là.
Tu y touches forcement -- tu y ajoutes un compilateur, au
moins. Et un éditeur (qui sous Windows est souvent integré avec
le compilateur dans in IDE). Sans doute un système de gestion
des sources aussi. Et je vois mal un projet d'une taille
respectable sans d'autres outils, du genre Rose ou Purify.
Ce que je voulais dire, c'est que l'on ajoute pas de .so externe à la
Et où est-ce que c'est plus grave que d'avoir ajouté un
compilateur ou un éditeur ? Sur certaines machines, tu as bien
un « environement de développement ». Cet environement comporte
pas mal d'outils divers, qui ne sont pas forcément présentent
sur les machines de production. Si tu veux utiliser Boost, tu
l'ajoutes à l'environement de développement, exactement comme tu
fais pour g++ ou VC++, Emacs ou vim, Clearcase, Purify, Rose, et
que sais-je de plus.
Sur la machine de test, avec la configuration des machines de
prod, évidemment, tu n'ajoutes pas le compilateur et al. Mais tu
n'as pas besoin de Boost là, non plus.
Oui, mais si je link mon binaire avec boost il faudra forcément que sur
Je ne suis pas sûr si j'ai compris. Il faut bien une machine
image de la production pour les tests. Mais on ne peut pas trop
y développer, étant donné que les machines de la production
n'ont pas de compilateur.
Une des contraintes est de ne pas toucher à la config, la STL
et X sont là.
Tu y touches forcement -- tu y ajoutes un compilateur, au
moins. Et un éditeur (qui sous Windows est souvent integré avec
le compilateur dans in IDE). Sans doute un système de gestion
des sources aussi. Et je vois mal un projet d'une taille
respectable sans d'autres outils, du genre Rose ou Purify.
Ce que je voulais dire, c'est que l'on ajoute pas de .so externe à la
Et où est-ce que c'est plus grave que d'avoir ajouté un
compilateur ou un éditeur ? Sur certaines machines, tu as bien
un « environement de développement ». Cet environement comporte
pas mal d'outils divers, qui ne sont pas forcément présentent
sur les machines de production. Si tu veux utiliser Boost, tu
l'ajoutes à l'environement de développement, exactement comme tu
fais pour g++ ou VC++, Emacs ou vim, Clearcase, Purify, Rose, et
que sais-je de plus.
Sur la machine de test, avec la configuration des machines de
prod, évidemment, tu n'ajoutes pas le compilateur et al. Mais tu
n'as pas besoin de Boost là, non plus.
Oui, mais si je link mon binaire avec boost il faudra forcément que sur
Je ne suis pas sûr si j'ai compris. Il faut bien une machine
image de la production pour les tests. Mais on ne peut pas trop
y développer, étant donné que les machines de la production
n'ont pas de compilateur.Une des contraintes est de ne pas toucher à la config, la STL
et X sont là.
Tu y touches forcement -- tu y ajoutes un compilateur, au
moins. Et un éditeur (qui sous Windows est souvent integré avec
le compilateur dans in IDE). Sans doute un système de gestion
des sources aussi. Et je vois mal un projet d'une taille
respectable sans d'autres outils, du genre Rose ou Purify.
Ce que je voulais dire, c'est que l'on ajoute pas de .so externe à la
Et où est-ce que c'est plus grave que d'avoir ajouté un
compilateur ou un éditeur ? Sur certaines machines, tu as bien
un « environement de développement ». Cet environement comporte
pas mal d'outils divers, qui ne sont pas forcément présentent
sur les machines de production. Si tu veux utiliser Boost, tu
l'ajoutes à l'environement de développement, exactement comme tu
fais pour g++ ou VC++, Emacs ou vim, Clearcase, Purify, Rose, et
que sais-je de plus.
Sur la machine de test, avec la configuration des machines de
prod, évidemment, tu n'ajoutes pas le compilateur et al. Mais tu
n'as pas besoin de Boost là, non plus.
Oui, mais si je link mon binaire avec boost il faudra forcément que sur
Oui, mais si je link mon binaire avec boost il faudra forcément que sur
la machine cible elle soit présente. (et lier certaines lib en dynamics
d'autre en static, je sais pas faire)
Oui, mais si je link mon binaire avec boost il faudra forcément que sur
la machine cible elle soit présente. (et lier certaines lib en dynamics
d'autre en static, je sais pas faire)
Oui, mais si je link mon binaire avec boost il faudra forcément que sur
la machine cible elle soit présente. (et lier certaines lib en dynamics
d'autre en static, je sais pas faire)
wrote:
[...]Je ne suis pas sûr si j'ai compris. Il faut bien une machine
image de la production pour les tests. Mais on ne peut pas
trop y développer, étant donné que les machines de la
production n'ont pas de compilateur.Une des contraintes est de ne pas toucher à la config, la
STL et X sont là.
Tu y touches forcement -- tu y ajoutes un compilateur, au
moins. Et un éditeur (qui sous Windows est souvent integré
avec le compilateur dans in IDE). Sans doute un système de
gestion des sources aussi. Et je vois mal un projet d'une
taille respectable sans d'autres outils, du genre Rose ou
Purify.
Ce que je voulais dire, c'est que l'on ajoute pas de .so
externe à la distribution standard, pour le moment.
Donc sur les machines de dev ont a la même config aux outils
de dev prêt.
L'installation du soft se résume :
copies dans le compte cible de 1 binaire, 5 fichiers de données/config,
1 .so (et 3 link)
Puis config de LD_LIBRARY_PATH (du compte cible) sur le .so.
Ce que je voulais éviter c'est le '.so' qui n'est pas de moi
et qui n'est pas présent dans la distrib.
[..]Et où est-ce que c'est plus grave que d'avoir ajouté un
compilateur ou un éditeur ? Sur certaines machines, tu as
bien un « environement de développement ». Cet environement
comporte pas mal d'outils divers, qui ne sont pas forcément
présentent sur les machines de production. Si tu veux
utiliser Boost, tu l'ajoutes à l'environement de
développement, exactement comme tu fais pour g++ ou VC++,
Emacs ou vim, Clearcase, Purify, Rose, et que sais-je de
plus.
Sur la machine de test, avec la configuration des machines
de prod, évidemment, tu n'ajoutes pas le compilateur et al.
Mais tu n'as pas besoin de Boost là, non plus.
Oui, mais si je link mon binaire avec boost il faudra
forcément que sur la machine cible elle soit présente.
(et lier certaines lib en dynamics d'autre en static, je sais
pas faire)
Boost m'interresse pour la manipulation des string mais plus
pour des contraintes contractuelles et de temps, je ne pouvais
me mettre à boost. J'ai d'autres bibliothèques, en plus de
boost, que je souhaiterais utiliser mais dont je me passe pour
le momment. Les contraintes contractuelles initialles ayant
été modifiés je vais pouvoir utiliser plus facilement des
bibliothèques externes à la distribution du momment ou
l'installation n'impact que le compte utilisateur ciblé.
kanze@gabi-soft.fr wrote:
[...]
Je ne suis pas sûr si j'ai compris. Il faut bien une machine
image de la production pour les tests. Mais on ne peut pas
trop y développer, étant donné que les machines de la
production n'ont pas de compilateur.
Une des contraintes est de ne pas toucher à la config, la
STL et X sont là.
Tu y touches forcement -- tu y ajoutes un compilateur, au
moins. Et un éditeur (qui sous Windows est souvent integré
avec le compilateur dans in IDE). Sans doute un système de
gestion des sources aussi. Et je vois mal un projet d'une
taille respectable sans d'autres outils, du genre Rose ou
Purify.
Ce que je voulais dire, c'est que l'on ajoute pas de .so
externe à la distribution standard, pour le moment.
Donc sur les machines de dev ont a la même config aux outils
de dev prêt.
L'installation du soft se résume :
copies dans le compte cible de 1 binaire, 5 fichiers de données/config,
1 .so (et 3 link)
Puis config de LD_LIBRARY_PATH (du compte cible) sur le .so.
Ce que je voulais éviter c'est le '.so' qui n'est pas de moi
et qui n'est pas présent dans la distrib.
[..]
Et où est-ce que c'est plus grave que d'avoir ajouté un
compilateur ou un éditeur ? Sur certaines machines, tu as
bien un « environement de développement ». Cet environement
comporte pas mal d'outils divers, qui ne sont pas forcément
présentent sur les machines de production. Si tu veux
utiliser Boost, tu l'ajoutes à l'environement de
développement, exactement comme tu fais pour g++ ou VC++,
Emacs ou vim, Clearcase, Purify, Rose, et que sais-je de
plus.
Sur la machine de test, avec la configuration des machines
de prod, évidemment, tu n'ajoutes pas le compilateur et al.
Mais tu n'as pas besoin de Boost là, non plus.
Oui, mais si je link mon binaire avec boost il faudra
forcément que sur la machine cible elle soit présente.
(et lier certaines lib en dynamics d'autre en static, je sais
pas faire)
Boost m'interresse pour la manipulation des string mais plus
pour des contraintes contractuelles et de temps, je ne pouvais
me mettre à boost. J'ai d'autres bibliothèques, en plus de
boost, que je souhaiterais utiliser mais dont je me passe pour
le momment. Les contraintes contractuelles initialles ayant
été modifiés je vais pouvoir utiliser plus facilement des
bibliothèques externes à la distribution du momment ou
l'installation n'impact que le compte utilisateur ciblé.
wrote:
[...]Je ne suis pas sûr si j'ai compris. Il faut bien une machine
image de la production pour les tests. Mais on ne peut pas
trop y développer, étant donné que les machines de la
production n'ont pas de compilateur.Une des contraintes est de ne pas toucher à la config, la
STL et X sont là.
Tu y touches forcement -- tu y ajoutes un compilateur, au
moins. Et un éditeur (qui sous Windows est souvent integré
avec le compilateur dans in IDE). Sans doute un système de
gestion des sources aussi. Et je vois mal un projet d'une
taille respectable sans d'autres outils, du genre Rose ou
Purify.
Ce que je voulais dire, c'est que l'on ajoute pas de .so
externe à la distribution standard, pour le moment.
Donc sur les machines de dev ont a la même config aux outils
de dev prêt.
L'installation du soft se résume :
copies dans le compte cible de 1 binaire, 5 fichiers de données/config,
1 .so (et 3 link)
Puis config de LD_LIBRARY_PATH (du compte cible) sur le .so.
Ce que je voulais éviter c'est le '.so' qui n'est pas de moi
et qui n'est pas présent dans la distrib.
[..]Et où est-ce que c'est plus grave que d'avoir ajouté un
compilateur ou un éditeur ? Sur certaines machines, tu as
bien un « environement de développement ». Cet environement
comporte pas mal d'outils divers, qui ne sont pas forcément
présentent sur les machines de production. Si tu veux
utiliser Boost, tu l'ajoutes à l'environement de
développement, exactement comme tu fais pour g++ ou VC++,
Emacs ou vim, Clearcase, Purify, Rose, et que sais-je de
plus.
Sur la machine de test, avec la configuration des machines
de prod, évidemment, tu n'ajoutes pas le compilateur et al.
Mais tu n'as pas besoin de Boost là, non plus.
Oui, mais si je link mon binaire avec boost il faudra
forcément que sur la machine cible elle soit présente.
(et lier certaines lib en dynamics d'autre en static, je sais
pas faire)
Boost m'interresse pour la manipulation des string mais plus
pour des contraintes contractuelles et de temps, je ne pouvais
me mettre à boost. J'ai d'autres bibliothèques, en plus de
boost, que je souhaiterais utiliser mais dont je me passe pour
le momment. Les contraintes contractuelles initialles ayant
été modifiés je vais pouvoir utiliser plus facilement des
bibliothèques externes à la distribution du momment ou
l'installation n'impact que le compte utilisateur ciblé.
