Ceci est la suite (et fin j'espère) du fil [Quel conteneur choisir].
Voici ce que j'ai :
class Attribute
{
public:
Attribute(const std::string& val, const Config& rcConf)
: m_sValue(val), m_rcConf(rcConf) {}
std::string m_sValue;
const Config& m_rcConf;
};
typedef std::vector<Attribute> TAttributes;
Comme je n'ai pas de constructeur par défaut (impossible a cause du
membre m_rcConf qui est une référence, je ne vois pas comment utiliser
le conteneur std::vector<>.
Avec std::map<>, je n'avais pas le problème, car la méthode
insert ne crée pas d'abord l'élément dans la map grâce au
constructeur par défaut.
Ca m'ennuie de transformer ma référence en pointeur :
class Attribute
{
public:
Attribute(const std::string& val = "", const Config* pConf = NULL)
: m_sValue(val), m_rcConf(rcConf) {}
std::string m_sValue;
const Config* m_pcConf;
};
Bien sur, je peux utiliser std::list<>, qui me permettra de parer le
problème, mais je me disais que c'était l'occasion de /jouer/ avec
std::vector que je n'ai pas l'habitude d'utiliser (contrairement a
beaucoup d'entre vous qui, d'apres ce que j'ai compris, utilisaient
souvent std::vector<> comme conteneur par defaut).
Y a t il une solution avec std::vector<> ?
Ceci est la suite (et fin j'espère) du fil [Quel conteneur choisir].
Voici ce que j'ai :
class Attribute
{
public:
Attribute(const std::string& val, const Config& rcConf)
: m_sValue(val), m_rcConf(rcConf) {}
std::string m_sValue;
const Config& m_rcConf;
};
typedef std::vector<Attribute> TAttributes;
Comme je n'ai pas de constructeur par défaut (impossible a cause du
membre m_rcConf qui est une référence, je ne vois pas comment utiliser
le conteneur std::vector<>.
Avec std::map<>, je n'avais pas le problème, car la méthode
insert ne crée pas d'abord l'élément dans la map grâce au
constructeur par défaut.
Ca m'ennuie de transformer ma référence en pointeur :
class Attribute
{
public:
Attribute(const std::string& val = "", const Config* pConf = NULL)
: m_sValue(val), m_rcConf(rcConf) {}
std::string m_sValue;
const Config* m_pcConf;
};
Bien sur, je peux utiliser std::list<>, qui me permettra de parer le
problème, mais je me disais que c'était l'occasion de /jouer/ avec
std::vector que je n'ai pas l'habitude d'utiliser (contrairement a
beaucoup d'entre vous qui, d'apres ce que j'ai compris, utilisaient
souvent std::vector<> comme conteneur par defaut).
Y a t il une solution avec std::vector<> ?
Ceci est la suite (et fin j'espère) du fil [Quel conteneur choisir].
Voici ce que j'ai :
class Attribute
{
public:
Attribute(const std::string& val, const Config& rcConf)
: m_sValue(val), m_rcConf(rcConf) {}
std::string m_sValue;
const Config& m_rcConf;
};
typedef std::vector<Attribute> TAttributes;
Comme je n'ai pas de constructeur par défaut (impossible a cause du
membre m_rcConf qui est une référence, je ne vois pas comment utiliser
le conteneur std::vector<>.
Avec std::map<>, je n'avais pas le problème, car la méthode
insert ne crée pas d'abord l'élément dans la map grâce au
constructeur par défaut.
Ca m'ennuie de transformer ma référence en pointeur :
class Attribute
{
public:
Attribute(const std::string& val = "", const Config* pConf = NULL)
: m_sValue(val), m_rcConf(rcConf) {}
std::string m_sValue;
const Config* m_pcConf;
};
Bien sur, je peux utiliser std::list<>, qui me permettra de parer le
problème, mais je me disais que c'était l'occasion de /jouer/ avec
std::vector que je n'ai pas l'habitude d'utiliser (contrairement a
beaucoup d'entre vous qui, d'apres ce que j'ai compris, utilisaient
souvent std::vector<> comme conteneur par defaut).
Y a t il une solution avec std::vector<> ?
On Jun 17, 8:01 pm, jeremie fouche wrote:Ceci est la suite (et fin j'espère) du fil [Quel conteneur choisir].
Voici ce que j'ai :
class Attribute
{
public:
Attribute(const std::string& val, const Config& rcConf)
: m_sValue(val), m_rcConf(rcConf) {}
std::string m_sValue;
const Config& m_rcConf;
};
typedef std::vector<Attribute> TAttributes;
Comme je n'ai pas de constructeur par défaut (impossible a cause du
membre m_rcConf qui est une référence, je ne vois pas comment utiliser
le conteneur std::vector<>.
Le problème ici, ce n'est pas l'absence d'un constructeur par
défaut (vector n'en a pas besoin), mais d'un opérateur
d'affectation (dont ont besoin toutes les collections).
Avec std::map<>, je n'avais pas le problème, car la méthode
insert ne crée pas d'abord l'élément dans la map grâce au
constructeur par défaut.
La fonction operator[], en revanche, si.
Bien sur, je peux utiliser std::list<>, qui me permettra de parer le
problème, mais je me disais que c'était l'occasion de /jouer/ avec
std::vector que je n'ai pas l'habitude d'utiliser (contrairement a
beaucoup d'entre vous qui, d'apres ce que j'ai compris, utilisaient
souvent std::vector<> comme conteneur par defaut).
Ça ne marche pas mieux avec std::list. G++, au moins, râle qu'il
manque un opérateur d'affectation dans les deux cas.
On Jun 17, 8:01 pm, jeremie fouche <jfou...@voila.fr> wrote:
Ceci est la suite (et fin j'espère) du fil [Quel conteneur choisir].
Voici ce que j'ai :
class Attribute
{
public:
Attribute(const std::string& val, const Config& rcConf)
: m_sValue(val), m_rcConf(rcConf) {}
std::string m_sValue;
const Config& m_rcConf;
};
typedef std::vector<Attribute> TAttributes;
Comme je n'ai pas de constructeur par défaut (impossible a cause du
membre m_rcConf qui est une référence, je ne vois pas comment utiliser
le conteneur std::vector<>.
Le problème ici, ce n'est pas l'absence d'un constructeur par
défaut (vector n'en a pas besoin), mais d'un opérateur
d'affectation (dont ont besoin toutes les collections).
Avec std::map<>, je n'avais pas le problème, car la méthode
insert ne crée pas d'abord l'élément dans la map grâce au
constructeur par défaut.
La fonction operator[], en revanche, si.
Bien sur, je peux utiliser std::list<>, qui me permettra de parer le
problème, mais je me disais que c'était l'occasion de /jouer/ avec
std::vector que je n'ai pas l'habitude d'utiliser (contrairement a
beaucoup d'entre vous qui, d'apres ce que j'ai compris, utilisaient
souvent std::vector<> comme conteneur par defaut).
Ça ne marche pas mieux avec std::list. G++, au moins, râle qu'il
manque un opérateur d'affectation dans les deux cas.
On Jun 17, 8:01 pm, jeremie fouche wrote:Ceci est la suite (et fin j'espère) du fil [Quel conteneur choisir].
Voici ce que j'ai :
class Attribute
{
public:
Attribute(const std::string& val, const Config& rcConf)
: m_sValue(val), m_rcConf(rcConf) {}
std::string m_sValue;
const Config& m_rcConf;
};
typedef std::vector<Attribute> TAttributes;
Comme je n'ai pas de constructeur par défaut (impossible a cause du
membre m_rcConf qui est une référence, je ne vois pas comment utiliser
le conteneur std::vector<>.
Le problème ici, ce n'est pas l'absence d'un constructeur par
défaut (vector n'en a pas besoin), mais d'un opérateur
d'affectation (dont ont besoin toutes les collections).
Avec std::map<>, je n'avais pas le problème, car la méthode
insert ne crée pas d'abord l'élément dans la map grâce au
constructeur par défaut.
La fonction operator[], en revanche, si.
Bien sur, je peux utiliser std::list<>, qui me permettra de parer le
problème, mais je me disais que c'était l'occasion de /jouer/ avec
std::vector que je n'ai pas l'habitude d'utiliser (contrairement a
beaucoup d'entre vous qui, d'apres ce que j'ai compris, utilisaient
souvent std::vector<> comme conteneur par defaut).
Ça ne marche pas mieux avec std::list. G++, au moins, râle qu'il
manque un opérateur d'affectation dans les deux cas.
- operateur = me semble trivial pour une référence
- operateur = me semble trivial pour une référence
- operateur = me semble trivial pour une référence
On Sun, 17 Jun 2007 23:02:02 +0200, jeremie fouche :- operateur = me semble trivial pour une référence
Pas du tout. Il est impossible de modifier une référence.
En général, si une classe contient une référence, l'affectation n'est
pas possible.
Pour pouvoir définir un opérateur d'affectation, tu voudras
probablement remplacer ta référence par un pointeur.
On Sun, 17 Jun 2007 23:02:02 +0200, jeremie fouche <jfouche@voila.fr>:
- operateur = me semble trivial pour une référence
Pas du tout. Il est impossible de modifier une référence.
En général, si une classe contient une référence, l'affectation n'est
pas possible.
Pour pouvoir définir un opérateur d'affectation, tu voudras
probablement remplacer ta référence par un pointeur.
On Sun, 17 Jun 2007 23:02:02 +0200, jeremie fouche :- operateur = me semble trivial pour une référence
Pas du tout. Il est impossible de modifier une référence.
En général, si une classe contient une référence, l'affectation n'est
pas possible.
Pour pouvoir définir un opérateur d'affectation, tu voudras
probablement remplacer ta référence par un pointeur.
Je suis tout de meme un peu perdu, car l'affectation fonctionne
parfaitement dans du code :
const Attribute& rcAttribute = (*iteratorSurVectorAttribute);
Et pourquoi ca marche avec le std::list<> ?
Je suis tout de meme un peu perdu, car l'affectation fonctionne
parfaitement dans du code :
const Attribute& rcAttribute = (*iteratorSurVectorAttribute);
Et pourquoi ca marche avec le std::list<> ?
Je suis tout de meme un peu perdu, car l'affectation fonctionne
parfaitement dans du code :
const Attribute& rcAttribute = (*iteratorSurVectorAttribute);
Et pourquoi ca marche avec le std::list<> ?
On Sun, 17 Jun 2007 23:11:43 +0200, jeremie fouche :Je suis tout de meme un peu perdu, car l'affectation fonctionne
parfaitement dans du code :
const Attribute& rcAttribute = (*iteratorSurVectorAttribute);
Ceci n'est pas une affectation, c'est une initialisation.
int a (12); -> constructeur de copie
int a= 12; -> même chose
int a; -> constructeur par défaut
a= 12; -> affectation
Et pourquoi ca marche avec le std::list<> ?
Si le standard indique qu'un bout de code a un "comportement
indéfini", tout peut arriver. Le compilateur peut refuser le code ; ou
bien, le code peut compiler, mais planter une fois sur deux, ou (plus
gênant), fonctionner parfaitement sur ta machine, mais pas sur la
machine du client, etc.
On Sun, 17 Jun 2007 23:11:43 +0200, jeremie fouche <jfouche@voila.fr>:
Je suis tout de meme un peu perdu, car l'affectation fonctionne
parfaitement dans du code :
const Attribute& rcAttribute = (*iteratorSurVectorAttribute);
Ceci n'est pas une affectation, c'est une initialisation.
int a (12); -> constructeur de copie
int a= 12; -> même chose
int a; -> constructeur par défaut
a= 12; -> affectation
Et pourquoi ca marche avec le std::list<> ?
Si le standard indique qu'un bout de code a un "comportement
indéfini", tout peut arriver. Le compilateur peut refuser le code ; ou
bien, le code peut compiler, mais planter une fois sur deux, ou (plus
gênant), fonctionner parfaitement sur ta machine, mais pas sur la
machine du client, etc.
On Sun, 17 Jun 2007 23:11:43 +0200, jeremie fouche :Je suis tout de meme un peu perdu, car l'affectation fonctionne
parfaitement dans du code :
const Attribute& rcAttribute = (*iteratorSurVectorAttribute);
Ceci n'est pas une affectation, c'est une initialisation.
int a (12); -> constructeur de copie
int a= 12; -> même chose
int a; -> constructeur par défaut
a= 12; -> affectation
Et pourquoi ca marche avec le std::list<> ?
Si le standard indique qu'un bout de code a un "comportement
indéfini", tout peut arriver. Le compilateur peut refuser le code ; ou
bien, le code peut compiler, mais planter une fois sur deux, ou (plus
gênant), fonctionner parfaitement sur ta machine, mais pas sur la
machine du client, etc.
On Jun 17, 8:01 pm, jeremie fouche wrote:Ceci est la suite (et fin j'espère) du fil [Quel conteneur choisir].
Voici ce que j'ai :
class Attribute
{
public:
Attribute(const std::string& val, const Config& rcConf)
: m_sValue(val), m_rcConf(rcConf) {}
std::string m_sValue;
const Config& m_rcConf;
};
typedef std::vector<Attribute> TAttributes;
Comme je n'ai pas de constructeur par défaut (impossible a cause du
membre m_rcConf qui est une référence, je ne vois pas comment util iser
le conteneur std::vector<>.
Le problème ici, ce n'est pas l'absence d'un constructeur par
défaut (vector n'en a pas besoin), mais d'un opérateur
d'affectation (dont ont besoin toutes les collections).
J'avais donc mal compris le problème...
Arrêtes moi si je me trompe : Il me semblais que l'opérateur
d'affectation était généré automatiquement par le compilateur, en
effectuant l'opérateur d'affectation pour chaque membre de la classe. En
revanche, cela ne semble pas posé de problème a priori :
- operateur = est défini pour std::string
- operateur = me semble trivial pour une référence, donc généra ble
automatiquement par le compilateur.
Donc si j'ai bien compris, il suffirait que j'implemente
l'operateur = ? (non testé)
class Attribute
{
public:
Attribute(const std::string& val, const Config& rcConf)
: m_sValue(val), m_rcConf(rcConf) {}
Attribute& operateur = (const Attribute& rcAttribute)
{
if (this != &rcAttribute)
{
sValue = rcAttribute.sValue;
m_rcConf = rcAttribute.m_rcConf;
}
return *this
}
std::string m_sValue;
const Config& m_rcConf;
};
Mais il me semblait que c'était le code généré automatiquement
par le compilateur.
Avec std::map<>, je n'avais pas le problème, car la méthode
insert ne crée pas d'abord l'élément dans la map grâce au
constructeur par défaut.
La fonction operator[], en revanche, si.
Effectivement, c'est la raison pour laquelle j'utilisais la
méthode insert().Bien sur, je peux utiliser std::list<>, qui me permettra de parer le
problème, mais je me disais que c'était l'occasion de /jouer/ avec
std::vector que je n'ai pas l'habitude d'utiliser (contrairement a
beaucoup d'entre vous qui, d'apres ce que j'ai compris, utilisaient
souvent std::vector<> comme conteneur par defaut).
Ça ne marche pas mieux avec std::list. G++, au moins, râle qu'il
manque un opérateur d'affectation dans les deux cas.
C'est surprenant, mon g++ (3.4.2) sous MinGW ne me dit rien... J'ai
juste transformé mon typedef std::vector<Attribute> en
std::list<Attribute>, et tout fonctionne comme sur des roulettes.
On Jun 17, 8:01 pm, jeremie fouche <jfou...@voila.fr> wrote:
Ceci est la suite (et fin j'espère) du fil [Quel conteneur choisir].
Voici ce que j'ai :
class Attribute
{
public:
Attribute(const std::string& val, const Config& rcConf)
: m_sValue(val), m_rcConf(rcConf) {}
std::string m_sValue;
const Config& m_rcConf;
};
typedef std::vector<Attribute> TAttributes;
Comme je n'ai pas de constructeur par défaut (impossible a cause du
membre m_rcConf qui est une référence, je ne vois pas comment util iser
le conteneur std::vector<>.
Le problème ici, ce n'est pas l'absence d'un constructeur par
défaut (vector n'en a pas besoin), mais d'un opérateur
d'affectation (dont ont besoin toutes les collections).
J'avais donc mal compris le problème...
Arrêtes moi si je me trompe : Il me semblais que l'opérateur
d'affectation était généré automatiquement par le compilateur, en
effectuant l'opérateur d'affectation pour chaque membre de la classe. En
revanche, cela ne semble pas posé de problème a priori :
- operateur = est défini pour std::string
- operateur = me semble trivial pour une référence, donc généra ble
automatiquement par le compilateur.
Donc si j'ai bien compris, il suffirait que j'implemente
l'operateur = ? (non testé)
class Attribute
{
public:
Attribute(const std::string& val, const Config& rcConf)
: m_sValue(val), m_rcConf(rcConf) {}
Attribute& operateur = (const Attribute& rcAttribute)
{
if (this != &rcAttribute)
{
sValue = rcAttribute.sValue;
m_rcConf = rcAttribute.m_rcConf;
}
return *this
}
std::string m_sValue;
const Config& m_rcConf;
};
Mais il me semblait que c'était le code généré automatiquement
par le compilateur.
Avec std::map<>, je n'avais pas le problème, car la méthode
insert ne crée pas d'abord l'élément dans la map grâce au
constructeur par défaut.
La fonction operator[], en revanche, si.
Effectivement, c'est la raison pour laquelle j'utilisais la
méthode insert().
Bien sur, je peux utiliser std::list<>, qui me permettra de parer le
problème, mais je me disais que c'était l'occasion de /jouer/ avec
std::vector que je n'ai pas l'habitude d'utiliser (contrairement a
beaucoup d'entre vous qui, d'apres ce que j'ai compris, utilisaient
souvent std::vector<> comme conteneur par defaut).
Ça ne marche pas mieux avec std::list. G++, au moins, râle qu'il
manque un opérateur d'affectation dans les deux cas.
C'est surprenant, mon g++ (3.4.2) sous MinGW ne me dit rien... J'ai
juste transformé mon typedef std::vector<Attribute> en
std::list<Attribute>, et tout fonctionne comme sur des roulettes.
On Jun 17, 8:01 pm, jeremie fouche wrote:Ceci est la suite (et fin j'espère) du fil [Quel conteneur choisir].
Voici ce que j'ai :
class Attribute
{
public:
Attribute(const std::string& val, const Config& rcConf)
: m_sValue(val), m_rcConf(rcConf) {}
std::string m_sValue;
const Config& m_rcConf;
};
typedef std::vector<Attribute> TAttributes;
Comme je n'ai pas de constructeur par défaut (impossible a cause du
membre m_rcConf qui est une référence, je ne vois pas comment util iser
le conteneur std::vector<>.
Le problème ici, ce n'est pas l'absence d'un constructeur par
défaut (vector n'en a pas besoin), mais d'un opérateur
d'affectation (dont ont besoin toutes les collections).
J'avais donc mal compris le problème...
Arrêtes moi si je me trompe : Il me semblais que l'opérateur
d'affectation était généré automatiquement par le compilateur, en
effectuant l'opérateur d'affectation pour chaque membre de la classe. En
revanche, cela ne semble pas posé de problème a priori :
- operateur = est défini pour std::string
- operateur = me semble trivial pour une référence, donc généra ble
automatiquement par le compilateur.
Donc si j'ai bien compris, il suffirait que j'implemente
l'operateur = ? (non testé)
class Attribute
{
public:
Attribute(const std::string& val, const Config& rcConf)
: m_sValue(val), m_rcConf(rcConf) {}
Attribute& operateur = (const Attribute& rcAttribute)
{
if (this != &rcAttribute)
{
sValue = rcAttribute.sValue;
m_rcConf = rcAttribute.m_rcConf;
}
return *this
}
std::string m_sValue;
const Config& m_rcConf;
};
Mais il me semblait que c'était le code généré automatiquement
par le compilateur.
Avec std::map<>, je n'avais pas le problème, car la méthode
insert ne crée pas d'abord l'élément dans la map grâce au
constructeur par défaut.
La fonction operator[], en revanche, si.
Effectivement, c'est la raison pour laquelle j'utilisais la
méthode insert().Bien sur, je peux utiliser std::list<>, qui me permettra de parer le
problème, mais je me disais que c'était l'occasion de /jouer/ avec
std::vector que je n'ai pas l'habitude d'utiliser (contrairement a
beaucoup d'entre vous qui, d'apres ce que j'ai compris, utilisaient
souvent std::vector<> comme conteneur par defaut).
Ça ne marche pas mieux avec std::list. G++, au moins, râle qu'il
manque un opérateur d'affectation dans les deux cas.
C'est surprenant, mon g++ (3.4.2) sous MinGW ne me dit rien... J'ai
juste transformé mon typedef std::vector<Attribute> en
std::list<Attribute>, et tout fonctionne comme sur des roulettes.
Pour terminer, faut il que je change ce que j'ai actuellement ?
Car ce logiciel DOIT etre multi-plateforme, donc compilé sur
PC, linux, MAC. Et pour information, ou peux tu voir que le
standard indique qu'un bout de code a un "comportement
indéfini" ?
Pour terminer, faut il que je change ce que j'ai actuellement ?
Car ce logiciel DOIT etre multi-plateforme, donc compilé sur
PC, linux, MAC. Et pour information, ou peux tu voir que le
standard indique qu'un bout de code a un "comportement
indéfini" ?
Pour terminer, faut il que je change ce que j'ai actuellement ?
Car ce logiciel DOIT etre multi-plateforme, donc compilé sur
PC, linux, MAC. Et pour information, ou peux tu voir que le
standard indique qu'un bout de code a un "comportement
indéfini" ?
D'après ma propre expérience, des références sont assez rare
comme membre, et typiquement elles ne servent que pour des
choses qui ne font pas partie de la représentation valeur de
l'objet. Et ne sont pas copiées lors d'une affectation.
D'après ma propre expérience, des références sont assez rare
comme membre, et typiquement elles ne servent que pour des
choses qui ne font pas partie de la représentation valeur de
l'objet. Et ne sont pas copiées lors d'une affectation.
D'après ma propre expérience, des références sont assez rare
comme membre, et typiquement elles ne servent que pour des
choses qui ne font pas partie de la représentation valeur de
l'objet. Et ne sont pas copiées lors d'une affectation.
D'après ma propre expérience, des références sont assez rare
comme membre, et typiquement elles ne servent que pour des
choses qui ne font pas partie de la représentation valeur de
l'objet. Et ne sont pas copiées lors d'une affectation.
Typiquement, dans mes programmes, quand j'ai des références en variab le
membre, c'est assez souvent dans l'implémentation du RAII, ce qui entre
dans tes critères. A part ça, c'est une chose qui m'arrive assez rare ment.
D'après ma propre expérience, des références sont assez rare
comme membre, et typiquement elles ne servent que pour des
choses qui ne font pas partie de la représentation valeur de
l'objet. Et ne sont pas copiées lors d'une affectation.
Typiquement, dans mes programmes, quand j'ai des références en variab le
membre, c'est assez souvent dans l'implémentation du RAII, ce qui entre
dans tes critères. A part ça, c'est une chose qui m'arrive assez rare ment.
D'après ma propre expérience, des références sont assez rare
comme membre, et typiquement elles ne servent que pour des
choses qui ne font pas partie de la représentation valeur de
l'objet. Et ne sont pas copiées lors d'une affectation.
Typiquement, dans mes programmes, quand j'ai des références en variab le
membre, c'est assez souvent dans l'implémentation du RAII, ce qui entre
dans tes critères. A part ça, c'est une chose qui m'arrive assez rare ment.