class cmd{
public:
static vector<cmd*> histo;
class cmd{
public:
static vector<cmd*> histo;
class cmd{
public:
static vector<cmd*> histo;
static vector<cmd*> histo;
genre cmd::cmd() { histo.push_back( this ) };
static vector<cmd*> histo;
genre cmd::cmd() { histo.push_back( this ) };
static vector<cmd*> histo;
genre cmd::cmd() { histo.push_back( this ) };
Par contre, j'ai toujours le pb suivant :
Apparemment, dans le constructeur mon vector se rempli bien ( size
s'incrémente bien),
mais la fonction GetHistorique me retourne un vector qui est vide.
Où est le problème ?
Par contre, j'ai toujours le pb suivant :
Apparemment, dans le constructeur mon vector se rempli bien ( size
s'incrémente bien),
mais la fonction GetHistorique me retourne un vector qui est vide.
Où est le problème ?
Par contre, j'ai toujours le pb suivant :
Apparemment, dans le constructeur mon vector se rempli bien ( size
s'incrémente bien),
mais la fonction GetHistorique me retourne un vector qui est vide.
Où est le problème ?
Si c'est pour un historique, je pense que stocker des pointeurs n'est pas
une bonne idée.
Il faudrait plutot stocker par valeur.
Et est-ce vraiment nécessaire de stocker carrément la classe ? Car je ne
sais pas ce que tu veux en faire exactement mais moi je stockerai plutot un
std::string décrivant la classe...
Si c'est pour un historique, je pense que stocker des pointeurs n'est pas
une bonne idée.
Il faudrait plutot stocker par valeur.
Et est-ce vraiment nécessaire de stocker carrément la classe ? Car je ne
sais pas ce que tu veux en faire exactement mais moi je stockerai plutot un
std::string décrivant la classe...
Si c'est pour un historique, je pense que stocker des pointeurs n'est pas
une bonne idée.
Il faudrait plutot stocker par valeur.
Et est-ce vraiment nécessaire de stocker carrément la classe ? Car je ne
sais pas ce que tu veux en faire exactement mais moi je stockerai plutot un
std::string décrivant la classe...
J'ai créé une classe de base du style
class cmd{
public:
cmd();
virtual ~cmd();
virtual void set();
virtual void get();
};
dont hérite d'autres classes plus spécifiques...
Je souhaiterai avoir un historique de chaque commande créée (
de façon statique ou dynamique ) durant l'execution de
l'application.
J'avais pensé à un vector comme par ex :
class cmd{
public:
static vector<cmd*> histo;
cmd( );
virtual ~cmd( );
virtual void set( );
virtual void get( );
virtual void PrintInfos( );
};
qui serait actualisé par le conctructeur de la classe de base
genre cmd::cmd() { histo.push_back( this ) };
et de manière approprié dans le destructeur.
Conceptuellement, cette approche vous semble-t-elle bonne ?
Par contre, en l'essayant, j'ai rencontré un pb étonnant :
Depuis une fonction je veux faire :
void GestionHisto( )
{
cmd* t=0;
for( int i=0; i < cmd::histo.size( ) ; i++)
{
t = cmd::histo[i];
if( t ) f->PrintInfos( )
}
}
Et là, ça ne marche pas, size( ) revoie tjours 0, alors qu'une
trace dans le constructeur de la classe de base m'indique que
size( ) s'incrémente bien à chaque création d'une commande.
Un avis sur la question ?
J'ai créé une classe de base du style
class cmd{
public:
cmd();
virtual ~cmd();
virtual void set();
virtual void get();
};
dont hérite d'autres classes plus spécifiques...
Je souhaiterai avoir un historique de chaque commande créée (
de façon statique ou dynamique ) durant l'execution de
l'application.
J'avais pensé à un vector comme par ex :
class cmd{
public:
static vector<cmd*> histo;
cmd( );
virtual ~cmd( );
virtual void set( );
virtual void get( );
virtual void PrintInfos( );
};
qui serait actualisé par le conctructeur de la classe de base
genre cmd::cmd() { histo.push_back( this ) };
et de manière approprié dans le destructeur.
Conceptuellement, cette approche vous semble-t-elle bonne ?
Par contre, en l'essayant, j'ai rencontré un pb étonnant :
Depuis une fonction je veux faire :
void GestionHisto( )
{
cmd* t=0;
for( int i=0; i < cmd::histo.size( ) ; i++)
{
t = cmd::histo[i];
if( t ) f->PrintInfos( )
}
}
Et là, ça ne marche pas, size( ) revoie tjours 0, alors qu'une
trace dans le constructeur de la classe de base m'indique que
size( ) s'incrémente bien à chaque création d'une commande.
Un avis sur la question ?
J'ai créé une classe de base du style
class cmd{
public:
cmd();
virtual ~cmd();
virtual void set();
virtual void get();
};
dont hérite d'autres classes plus spécifiques...
Je souhaiterai avoir un historique de chaque commande créée (
de façon statique ou dynamique ) durant l'execution de
l'application.
J'avais pensé à un vector comme par ex :
class cmd{
public:
static vector<cmd*> histo;
cmd( );
virtual ~cmd( );
virtual void set( );
virtual void get( );
virtual void PrintInfos( );
};
qui serait actualisé par le conctructeur de la classe de base
genre cmd::cmd() { histo.push_back( this ) };
et de manière approprié dans le destructeur.
Conceptuellement, cette approche vous semble-t-elle bonne ?
Par contre, en l'essayant, j'ai rencontré un pb étonnant :
Depuis une fonction je veux faire :
void GestionHisto( )
{
cmd* t=0;
for( int i=0; i < cmd::histo.size( ) ; i++)
{
t = cmd::histo[i];
if( t ) f->PrintInfos( )
}
}
Et là, ça ne marche pas, size( ) revoie tjours 0, alors qu'une
trace dans le constructeur de la classe de base m'indique que
size( ) s'incrémente bien à chaque création d'une commande.
Un avis sur la question ?
Salut,
J'ai créé une classe de base
du style
class cmd{
public:
cmd();
virtual ~cmd();
virtual void set();
virtual void get();
};
dont hérite d'autres classes plus spécifiques...
Je souhaiterai avoir un historique de
chaque commande créée ( de façon statique ou dynamique )
durant l'execution de l'application.
J'avais pensé à un vector comme par ex :
class cmd{
public:
static vector<cmd*> histo;
cmd( );
virtual ~cmd( );
virtual void set( );
virtual void get( );
virtual void PrintInfos( );
};
qui serait actualisé par le conctructeur de la classe de base
genre cmd::cmd() { histo.push_back( this ) };
et de manière approprié dans le destructeur.
Conceptuellement, cette approche vous semble-t-elle bonne ?
Par contre, en l'essayant, j'ai rencontré un pb étonnant :
Depuis une fonction je veux faire :
void GestionHisto( )
{
cmd* t=0;
for( int i=0; i < cmd::histo.size( ) ; i++)
{
t = cmd::histo[i];
if( t ) f->PrintInfos( )
}
}
Salut,
J'ai créé une classe de base
du style
class cmd{
public:
cmd();
virtual ~cmd();
virtual void set();
virtual void get();
};
dont hérite d'autres classes plus spécifiques...
Je souhaiterai avoir un historique de
chaque commande créée ( de façon statique ou dynamique )
durant l'execution de l'application.
J'avais pensé à un vector comme par ex :
class cmd{
public:
static vector<cmd*> histo;
cmd( );
virtual ~cmd( );
virtual void set( );
virtual void get( );
virtual void PrintInfos( );
};
qui serait actualisé par le conctructeur de la classe de base
genre cmd::cmd() { histo.push_back( this ) };
et de manière approprié dans le destructeur.
Conceptuellement, cette approche vous semble-t-elle bonne ?
Par contre, en l'essayant, j'ai rencontré un pb étonnant :
Depuis une fonction je veux faire :
void GestionHisto( )
{
cmd* t=0;
for( int i=0; i < cmd::histo.size( ) ; i++)
{
t = cmd::histo[i];
if( t ) f->PrintInfos( )
}
}
Salut,
J'ai créé une classe de base
du style
class cmd{
public:
cmd();
virtual ~cmd();
virtual void set();
virtual void get();
};
dont hérite d'autres classes plus spécifiques...
Je souhaiterai avoir un historique de
chaque commande créée ( de façon statique ou dynamique )
durant l'execution de l'application.
J'avais pensé à un vector comme par ex :
class cmd{
public:
static vector<cmd*> histo;
cmd( );
virtual ~cmd( );
virtual void set( );
virtual void get( );
virtual void PrintInfos( );
};
qui serait actualisé par le conctructeur de la classe de base
genre cmd::cmd() { histo.push_back( this ) };
et de manière approprié dans le destructeur.
Conceptuellement, cette approche vous semble-t-elle bonne ?
Par contre, en l'essayant, j'ai rencontré un pb étonnant :
Depuis une fonction je veux faire :
void GestionHisto( )
{
cmd* t=0;
for( int i=0; i < cmd::histo.size( ) ; i++)
{
t = cmd::histo[i];
if( t ) f->PrintInfos( )
}
}
Conceptuellement, cette approche vous semble-t-elle bonne ?
En gros. Je l'utilise souvent. Deux problèmes cependant :
D'abord, tu parles d'une « historique ». Est-ce une historique,
où simplement une liste des objets qui existe à un moment
donné@? Parce que si c'est une historique, tu ne peux pas
stocker des pointeurs à des objets si l'objet sera détruit sans
que le pointeur soit enlevé de la collection. Et si on enlève
les pointeurs, ce n'est plus une historique, mais simplement un
régistre.
En fait, c'est juste pour savoir ce que tu essaies à faire.
La solution classique ici, c'est d'emballer l'objet avec l'histo
dans un singleton, une fonction statique qui en renvoie une
référence à l'objet, en se chargeant de le construire au premier
appel, un peu du genre :
std::vector< cmd* >&
cmd::histo() // fonction membre statique !
{
static std::vector< cmd* >* result
= new std::vector< cmd* > ;
return *result ;
}
(N'oublie pas le lock si tu es en multi-thread.)Et là, ça ne marche pas, size( ) revoie tjours 0, alors qu'une
trace dans le constructeur de la classe de base m'indique que
size( ) s'incrémente bien à chaque création d'une commande.
Un avis sur la question ?
Je parie que toutes tes commandes sont des objets statiques,
définis dans des sources autres que la source qui contient la
définition de cmd::histo (ou avant cette définition dans la même
source).
--
James Kanze GABI Software
Conceptuellement, cette approche vous semble-t-elle bonne ?
En gros. Je l'utilise souvent. Deux problèmes cependant :
D'abord, tu parles d'une « historique ». Est-ce une historique,
où simplement une liste des objets qui existe à un moment
donné@? Parce que si c'est une historique, tu ne peux pas
stocker des pointeurs à des objets si l'objet sera détruit sans
que le pointeur soit enlevé de la collection. Et si on enlève
les pointeurs, ce n'est plus une historique, mais simplement un
régistre.
En fait, c'est juste pour savoir ce que tu essaies à faire.
La solution classique ici, c'est d'emballer l'objet avec l'histo
dans un singleton, une fonction statique qui en renvoie une
référence à l'objet, en se chargeant de le construire au premier
appel, un peu du genre :
std::vector< cmd* >&
cmd::histo() // fonction membre statique !
{
static std::vector< cmd* >* result
= new std::vector< cmd* > ;
return *result ;
}
(N'oublie pas le lock si tu es en multi-thread.)
Et là, ça ne marche pas, size( ) revoie tjours 0, alors qu'une
trace dans le constructeur de la classe de base m'indique que
size( ) s'incrémente bien à chaque création d'une commande.
Un avis sur la question ?
Je parie que toutes tes commandes sont des objets statiques,
définis dans des sources autres que la source qui contient la
définition de cmd::histo (ou avant cette définition dans la même
source).
--
James Kanze GABI Software
Conceptuellement, cette approche vous semble-t-elle bonne ?
En gros. Je l'utilise souvent. Deux problèmes cependant :
D'abord, tu parles d'une « historique ». Est-ce une historique,
où simplement une liste des objets qui existe à un moment
donné@? Parce que si c'est une historique, tu ne peux pas
stocker des pointeurs à des objets si l'objet sera détruit sans
que le pointeur soit enlevé de la collection. Et si on enlève
les pointeurs, ce n'est plus une historique, mais simplement un
régistre.
En fait, c'est juste pour savoir ce que tu essaies à faire.
La solution classique ici, c'est d'emballer l'objet avec l'histo
dans un singleton, une fonction statique qui en renvoie une
référence à l'objet, en se chargeant de le construire au premier
appel, un peu du genre :
std::vector< cmd* >&
cmd::histo() // fonction membre statique !
{
static std::vector< cmd* >* result
= new std::vector< cmd* > ;
return *result ;
}
(N'oublie pas le lock si tu es en multi-thread.)Et là, ça ne marche pas, size( ) revoie tjours 0, alors qu'une
trace dans le constructeur de la classe de base m'indique que
size( ) s'incrémente bien à chaque création d'une commande.
Un avis sur la question ?
Je parie que toutes tes commandes sont des objets statiques,
définis dans des sources autres que la source qui contient la
définition de cmd::histo (ou avant cette définition dans la même
source).
--
James Kanze GABI Software
a écrit dans le message de
news:Conceptuellement, cette approche vous semble-t-elle bonne ?
En gros. Je l'utilise souvent. Deux problèmes cependant :
D'abord, tu parles d'une « historique ». Est-ce une
historique, où simplement une liste des objets qui existe à
un moment donné ? Parce que si c'est une historique, tu ne
peux pas stocker des pointeurs à des objets si l'objet sera
détruit sans
Même si c'est le destructeur du dit objet qui s'en charge ?
que le pointeur soit enlevé de la collection. Et si on
enlève les pointeurs, ce n'est plus une historique, mais
simplement un régistre.
En fait, c'est juste pour savoir ce que tu essaies à faire.
Effectivement, c'est plus un registre qu'un historique.
[...]La solution classique ici, c'est d'emballer l'objet avec
l'histo dans un singleton, une fonction statique qui en
renvoie une référence à l'objet, en se chargeant de le
construire au premier appel, un peu du genre :
std::vector< cmd* >&
cmd::histo() // fonction membre statique !
{
static std::vector< cmd* >* result
= new std::vector< cmd* > ;
return *result ;
}
(N'oublie pas le lock si tu es en multi-thread.)Et là, ça ne marche pas, size( ) revoie tjours 0, alors
qu'une trace dans le constructeur de la classe de base
m'indique que size( ) s'incrémente bien à chaque création
d'une commande.
Un avis sur la question ?
Je parie que toutes tes commandes sont des objets statiques,
définis dans des sources autres que la source qui contient
la définition de cmd::histo (ou avant cette définition dans
la même source).
Exact.
Ces objets sont statiques car je trouvais la représentation :
class Parametres{
public:
Parametres();
~Parametres();
DerivedCommand1 cmd1 ;
DerivedCommand2 cmd2 ;
DerivedCommand3 cmd3 ;
};
assez facile à utiliser :
...
Parametres params;
int value1 ;
string value2 ;
value1 = (int) params.cmd1;
value2 = (string) params.cmd2;
...
Sachant que les operators ( ) sont
définis dans les classes DerivedCommand.
Merci pour les suggestions.
En fait, cette aproche "d'historique" n'est pas primordiale,
c'etait juste une option que je vais laisser de côter...
<kanze@gabi-soft.fr> a écrit dans le message de
news:1107958402.257733.47450@l41g2000cwc.googlegroups.com...
Conceptuellement, cette approche vous semble-t-elle bonne ?
En gros. Je l'utilise souvent. Deux problèmes cependant :
D'abord, tu parles d'une « historique ». Est-ce une
historique, où simplement une liste des objets qui existe à
un moment donné ? Parce que si c'est une historique, tu ne
peux pas stocker des pointeurs à des objets si l'objet sera
détruit sans
Même si c'est le destructeur du dit objet qui s'en charge ?
que le pointeur soit enlevé de la collection. Et si on
enlève les pointeurs, ce n'est plus une historique, mais
simplement un régistre.
En fait, c'est juste pour savoir ce que tu essaies à faire.
Effectivement, c'est plus un registre qu'un historique.
[...]
La solution classique ici, c'est d'emballer l'objet avec
l'histo dans un singleton, une fonction statique qui en
renvoie une référence à l'objet, en se chargeant de le
construire au premier appel, un peu du genre :
std::vector< cmd* >&
cmd::histo() // fonction membre statique !
{
static std::vector< cmd* >* result
= new std::vector< cmd* > ;
return *result ;
}
(N'oublie pas le lock si tu es en multi-thread.)
Et là, ça ne marche pas, size( ) revoie tjours 0, alors
qu'une trace dans le constructeur de la classe de base
m'indique que size( ) s'incrémente bien à chaque création
d'une commande.
Un avis sur la question ?
Je parie que toutes tes commandes sont des objets statiques,
définis dans des sources autres que la source qui contient
la définition de cmd::histo (ou avant cette définition dans
la même source).
Exact.
Ces objets sont statiques car je trouvais la représentation :
class Parametres{
public:
Parametres();
~Parametres();
DerivedCommand1 cmd1 ;
DerivedCommand2 cmd2 ;
DerivedCommand3 cmd3 ;
};
assez facile à utiliser :
...
Parametres params;
int value1 ;
string value2 ;
value1 = (int) params.cmd1;
value2 = (string) params.cmd2;
...
Sachant que les operators ( ) sont
définis dans les classes DerivedCommand.
Merci pour les suggestions.
En fait, cette aproche "d'historique" n'est pas primordiale,
c'etait juste une option que je vais laisser de côter...
a écrit dans le message de
news:Conceptuellement, cette approche vous semble-t-elle bonne ?
En gros. Je l'utilise souvent. Deux problèmes cependant :
D'abord, tu parles d'une « historique ». Est-ce une
historique, où simplement une liste des objets qui existe à
un moment donné ? Parce que si c'est une historique, tu ne
peux pas stocker des pointeurs à des objets si l'objet sera
détruit sans
Même si c'est le destructeur du dit objet qui s'en charge ?
que le pointeur soit enlevé de la collection. Et si on
enlève les pointeurs, ce n'est plus une historique, mais
simplement un régistre.
En fait, c'est juste pour savoir ce que tu essaies à faire.
Effectivement, c'est plus un registre qu'un historique.
[...]La solution classique ici, c'est d'emballer l'objet avec
l'histo dans un singleton, une fonction statique qui en
renvoie une référence à l'objet, en se chargeant de le
construire au premier appel, un peu du genre :
std::vector< cmd* >&
cmd::histo() // fonction membre statique !
{
static std::vector< cmd* >* result
= new std::vector< cmd* > ;
return *result ;
}
(N'oublie pas le lock si tu es en multi-thread.)Et là, ça ne marche pas, size( ) revoie tjours 0, alors
qu'une trace dans le constructeur de la classe de base
m'indique que size( ) s'incrémente bien à chaque création
d'une commande.
Un avis sur la question ?
Je parie que toutes tes commandes sont des objets statiques,
définis dans des sources autres que la source qui contient
la définition de cmd::histo (ou avant cette définition dans
la même source).
Exact.
Ces objets sont statiques car je trouvais la représentation :
class Parametres{
public:
Parametres();
~Parametres();
DerivedCommand1 cmd1 ;
DerivedCommand2 cmd2 ;
DerivedCommand3 cmd3 ;
};
assez facile à utiliser :
...
Parametres params;
int value1 ;
string value2 ;
value1 = (int) params.cmd1;
value2 = (string) params.cmd2;
...
Sachant que les operators ( ) sont
définis dans les classes DerivedCommand.
Merci pour les suggestions.
En fait, cette aproche "d'historique" n'est pas primordiale,
c'etait juste une option que je vais laisser de côter...
Même si c'est le destructeur du dit objet qui s'en charge ?
Effectivement, c'est plus un registre qu'un historique.
D'accord. C'est peut-être une lacune dans mon français, mais
pour moi, le mot « historique » suggère ce que j'appellerais un
« audit trail » en anglais, c-à-d un enrégistrement de tout ce
qui s'est passé. (L'expression anglaise implique une finalité
d'apporter des preuves en cas de litige que je n'entends pas
dans le mot français, mais au niveau du programme, ce qu'on
fait, c'est pareil.)
[...]
En fait, cette aproche "d'historique" n'est pas primordiale,
c'etait juste une option que je vais laisser de côter...
Mais ce n'est pas difficile à implémenter ; il suffit d'utiliser
un singleton pour le map. Je le fais tout le temps. Je te dirais
de régarder la gestion des Option dans CommandLine à ma site,
sauf que 1) je doute que la site marche encore, et 2) j'ai
implémenté des critères de récherche assez complexe, ce qui
cache en grande partie la simplicité de base de ce que j'ai
fait. (Pour le premier, j'ai changé de fournisseur il y a neuf
mois, et je n'ai pas encore tout installé chez le nouveau --
j'ai fait l'erreur idiote de changer la machine, la version de
l'OS et le type de connection tous à la fois, et il me faut un
certain temps pour que tout rémarche correctement.)
Même si c'est le destructeur du dit objet qui s'en charge ?
Effectivement, c'est plus un registre qu'un historique.
D'accord. C'est peut-être une lacune dans mon français, mais
pour moi, le mot « historique » suggère ce que j'appellerais un
« audit trail » en anglais, c-à-d un enrégistrement de tout ce
qui s'est passé. (L'expression anglaise implique une finalité
d'apporter des preuves en cas de litige que je n'entends pas
dans le mot français, mais au niveau du programme, ce qu'on
fait, c'est pareil.)
[...]
En fait, cette aproche "d'historique" n'est pas primordiale,
c'etait juste une option que je vais laisser de côter...
Mais ce n'est pas difficile à implémenter ; il suffit d'utiliser
un singleton pour le map. Je le fais tout le temps. Je te dirais
de régarder la gestion des Option dans CommandLine à ma site,
sauf que 1) je doute que la site marche encore, et 2) j'ai
implémenté des critères de récherche assez complexe, ce qui
cache en grande partie la simplicité de base de ce que j'ai
fait. (Pour le premier, j'ai changé de fournisseur il y a neuf
mois, et je n'ai pas encore tout installé chez le nouveau --
j'ai fait l'erreur idiote de changer la machine, la version de
l'OS et le type de connection tous à la fois, et il me faut un
certain temps pour que tout rémarche correctement.)
Même si c'est le destructeur du dit objet qui s'en charge ?
Effectivement, c'est plus un registre qu'un historique.
D'accord. C'est peut-être une lacune dans mon français, mais
pour moi, le mot « historique » suggère ce que j'appellerais un
« audit trail » en anglais, c-à-d un enrégistrement de tout ce
qui s'est passé. (L'expression anglaise implique une finalité
d'apporter des preuves en cas de litige que je n'entends pas
dans le mot français, mais au niveau du programme, ce qu'on
fait, c'est pareil.)
[...]
En fait, cette aproche "d'historique" n'est pas primordiale,
c'etait juste une option que je vais laisser de côter...
Mais ce n'est pas difficile à implémenter ; il suffit d'utiliser
un singleton pour le map. Je le fais tout le temps. Je te dirais
de régarder la gestion des Option dans CommandLine à ma site,
sauf que 1) je doute que la site marche encore, et 2) j'ai
implémenté des critères de récherche assez complexe, ce qui
cache en grande partie la simplicité de base de ce que j'ai
fait. (Pour le premier, j'ai changé de fournisseur il y a neuf
mois, et je n'ai pas encore tout installé chez le nouveau --
j'ai fait l'erreur idiote de changer la machine, la version de
l'OS et le type de connection tous à la fois, et il me faut un
certain temps pour que tout rémarche correctement.)
