un petit probleme avec vector

ricky wrote:

bonjour

j ai un petit probleme idiot en voulant utiliser un vector

j ai construit une classe du style :
class Ligne
{
string var1;
string var2;
const int OK;
public:
Ligne():OK(0) { ... };
etc etc
}

[...]

il semble qu'il ne sache pas faire la copie

Ce serait logique : Comment copier une classe qui a un membre constant ?
Le compilateur n'est pas à même de le deviner(et probablement que toi
aussi tu dois peiner à écrire un constructeur de copie sensé).

(et un constructeur de copie
ne change pas le probleme) :
- in member fonction 'ligne& ligne::operator=(const Ligne &)'
- non static const member

L'opérateur = et le constructeur de copie sont sémentiquement proche,
mais dans le langage, ce sont des entités bien distinctes. Et ici, tu as
besoin du premier. D'ailleur, en général (je n'ai pas encore vu
d'exception) quand on doit définir un constructeur de copie, il faut
aussi définir un opérateur =, et réciproquement (le destructeur fait
aussi souvent partie du groupe, mais ton cas est une exception à la
règle : un destructeur par défaut convient bien).

--
Loïc

bonjour

Ce serait logique : Comment copier une classe qui a un membre constant ?
Le compilateur n'est pas à même de le deviner(et probablement que toi
aussi tu dois peiner à écrire un constructeur de copie sensé).

c est la que je coince ...
le membre est constant et defini dans le constructeur ... le compilo
n'aurait donc pas a deviner quoique ce soit : il a la valeur de mise non ?
c est donc une mauvaise idee de mettre des membres constants dans une
classe ?

d'exception) quand on doit définir un constructeur de copie, il faut
aussi définir un opérateur
sauf peut etre si on agit sur des types simples ?

merci de ta reponse
je vais de ce pas faire l'operateur = :-)

@+
ricky

On Thu, 13 Nov 2003 22:17:20 +0100, ricky <eric_nyme@yahoo.fr> wrote:

class Ligne
{
const int OK;
public:
Ligne():OK(0) { ... };

Si "OK" est initialisé systématiquement à 0, et ne peut pas être
modifié (puisqu'il est const), il devrait être un membre "static
const", ce qui résoudra le problème.

--
;-)

ricky wrote:

bonjour

Ce serait logique : Comment copier une classe qui a un membre constant
? Le compilateur n'est pas à même de le deviner(et probablement que
toi aussi tu dois peiner à écrire un constructeur de copie sensé).

c est la que je coince ...
le membre est constant et defini dans le constructeur ... le compilo
n'aurait donc pas a deviner quoique ce soit : il a la valeur de mise non ?

Dans ce que tu as écrit, la constante pourrait très bien être variable
en fonction de l'instance de classe considérée (j'espère être clair ;)).
Mais une fois initialisée, elle ne peut plus être modifiée.

class Constant
{
public:
Constant(int i) : myValue(i) {}
const int myValue;
};

int main()
{
Constant c1(42);
Constant c2(314);
}

c est donc une mauvaise idee de mettre des membres constants dans une
classe ?

Une constante non statique (donc propre à chaque instance) et une classe
copiable font effectivement mauvais ménage.
Peut-être, comme le suggère Fabien LE LEZ, voulais-tu définir une
constante statique de ta classe, qui alors ne posera aucun problème pour
la copie, puisqu'elle ne fait pas partie d'une instance, mais est
globale. Sans plus d'informations sur ton problème réel, difficile de
mieux t'aider.

--
Loïc

Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<bp0vhh$urs$1@news-reader2.wanadoo.fr>...

ricky wrote:

j ai un petit probleme idiot en voulant utiliser un vector

j ai construit une classe du style :
class Ligne
{
string var1;
string var2;
const int OK;
public:
Ligne():OK(0) { ... };
etc etc
}

[...]

il semble qu'il ne sache pas faire la copie

Ce serait logique : Comment copier une classe qui a un membre
constant ? Le compilateur n'est pas à même de le deviner(et
probablement que toi aussi tu dois peiner à écrire un constructeur de
copie sensé).

Le constructeur de copie ne pose pas de problème. (Bien que je suis un
peu scéptique ; en général, quand on veut de la copie, on veut aussi de
l'affectation, ce qui est logiquement impossible avec un élément const.)

(et un constructeur de copie
ne change pas le probleme) :
- in member fonction 'ligne& ligne::operator=(const Ligne &)'
- non static const member

L'opérateur = et le constructeur de copie sont sémentiquement proche,
mais dans le langage, ce sont des entités bien distinctes.

Et ici, tu as besoin du premier.

S'il utilise std::vector, il en a besoin des deux.

D'ailleur, en général (je n'ai pas encore vu d'exception) quand on
doit définir un constructeur de copie, il faut aussi définir un
opérateur =, et réciproquement (le destructeur fait aussi souvent
partie du groupe, mais ton cas est une exception à la règle : un
destructeur par défaut convient bien).

Je ne sais pas. S'il ôte le const, les versions fournies par le
compilateur marchent dans les trois cas (copie, affectation et
destruction). Et s'il ne l'ôte pas, je ne vois pas ce que pourrait être
la sémantique de l'affectation.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

kanze@gabi-soft.fr wrote in message news:<d6652001.0311140138.6b42f630@posting.google.com>...

Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<bp0vhh$urs$1@news-reader2.wanadoo.fr>...

L'opérateur = et le constructeur de copie sont sémentiquement proche,
mais dans le langage, ce sont des entités bien distinctes.

Et ici, tu as besoin du premier.

S'il utilise std::vector, il en a besoin des deux.

Ok, la norme stipule que les éléments d'un container doivent être
"Assignable", mais j'ai du mal à imaginer qu'une implémentation de
push_back() fasse appel à l'opérateur d'affectation (le posteur
initial parlait de problème de compilation lors de l'instantiation de
push_back()).
Je rate un truc évident?

Bertrand.

bonjour

Si "OK" est initialisé systématiquement à 0, et ne peut pas être
modifié (puisqu'il est const), il devrait être un membre "static
const", ce qui résoudra le problème.

merci de ta reponse .. j en etait venu a la meme conclusion mais avec
moins de certitude...

@+
ricky

bonjour

Dans ce que tu as écrit, la constante pourrait très bien être variable
en fonction de l'instance de classe considérée (j'espère être clair ;)).

oui la variation de la constante :-P
on connait en math lol

sans rire, je vien de comprendre ce qui me genait !

Une constante non statique (donc propre à chaque instance) et une classe
copiable font effectivement mauvais ménage.

oki, c'est la que je faisais ma betise...

globale. Sans plus d'informations sur ton problème réel, difficile de
mieux t'aider.

vous avez resolu le probleme :-)
effectivement, je suis parti sur l'idee qu'une constante etait ...
constante point final une fois definie quelque part ... en oubliant ces
problemes de classe!

@+
ricky

bonjour

S'il utilise std::vector, il en a besoin des deux.

oki je vais les faire :-)

finalement, il ne faut pas etre paresseux en cpp :-)
k'ai voulu m'eviter ces constructions .. pour rien en fait

@+
ricky

bonjour

push_back() fasse appel à l'opérateur d'affectation (le posteur
initial parlait de problème de compilation lors de l'instantiation de
push_back()).

oui , il etait gene par mes constantes , et aussi par la copie de ma
ligne dans mon objet fichier
j'ai verifie en essayant un truc du style ligne1 = ligne2, ce qui
donnait la meme erreur prouvant l'utilite de construire l'operateur =.

ensuite Ligne ligne1=ligne2 a donne l'erreur en relation avec le
constructeur par copie (ce qui est logique)...

donc selon ce que j'utilise, il me semble qu'il me faut l'un OU/ET
l'autre selon les cas

je vais donc faire les deux (qui seront quasiment identiques) et je ne
devrais plus avoir de probleme

@+
ricky