question constructeur recopie et héritage

Version imprimable

26/02/2009, 09h30
loicounet

question constructeur recopie et héritage

Bonjour,

petite question:

je suis en train de développer une nouvelle classe NoeudSrcBruit qui hérite d'une classe mère NoeudData.
dans la classe mère il n'y a pas de constructeur de recopie(code existant).

je tente d'en définir un dans la classe fille, le compilateur me jette: est ce normal?

je met le message d'erreur:

Citation:

NoeudSrcBruit.cc: In constructor NoeudSrcBruit::NoeudSrcBruit(NoeudSrcBruit*)»:
NoeudSrcBruit.cc:36: erreur: no matching function for call to «NoeudData::NoeudData()»
NoeudData.hh:100: note: candidats sont: NoeudData::NoeudData(TypeNodeData, int, char*, TypeVar*, ParamStatBruit*)
NoeudData.hh:53: note: NoeudData::NoeudData(const NoeudData&)

Au vue du message je dirais qu'il faut nécessairement que la classe mère possède le constructeur par recopie pour pouvoir le faire aussi dans la fille...

merci
26/02/2009, 09h52
koala01
Salut,

Essaye déjà d'invoquer explicitement le constructeur par copie de la classe mère, car, apparemment, le compilateur se plaint de l'absence d'un constructeur par défaut pur NoeudData...

De plus, le constructeur par copie prend, normalement, une référence constante comme paramètre ;)

Ainsi, le constructeur par copie de ta classe devrait prendre la forme de
Code:

1 2 3 4 5 NoeudSrcBruit::NoeudSrcBruit(NoeudSrcBruit const & rhs):NoeudData(rhs)/*, initialisation des membres propres de NoeudSrcBruit */ { }
Maintenant, le fait que tu parle de "noeud" me fait penser que tu travilles sans doute avec une forme proche de l'arbre (binaire ou multiple) ou de graphe...

Dés lors, je me demande s'il est opportun de laisser la possibilité de créer une copie d'une instance de ce type...
26/02/2009, 10h04
loicounet
En effet je travaille sur des arbres,c'est sur que ca peut etre dangereux quand j'y réfléchi.
je vais éviter donc.

Citation:

De plus, le constructeur par copie prend, normalement, une référence constante comme paramètre

oui je suis d'accord mais le compilo me jette quand je veux faire ça par exemple:
Code:

1 2 3 4 5 6 7 8 class NoeudSrcBruit : public NoeudData { protected: vector<string*> m_Q; public : vector<string*>& GetmQ(){return &m_Q;}
26/02/2009, 10h52
koala01
Citation:

Envoyé par loicounet

En effet je travaille sur des arbres,c'est sur que ca peut etre dangereux quand j'y réfléchi.
je vais éviter donc.

Une sage décision ;)
Citation:
oui je suis d'accord mais le compilo me jette quand je veux faire ça par exemple:

Code:

1 2 3 4 5 6 7 class NoeudSrcBruit : public NoeudData { protected: vector<string*> m_Q; public : vector<string*>& GetmQ(){return &m_Q;}
Mais là, tu dit que GetmQ renvoie une référence et tu lui fait renvoyer... un pointeur... ne t'étonne dés lors pas que le compilateur te jette ;)

Pour que GetmQ() enrevoie effectivement une référence, c'est sous la forme de

Code:

vector<string*>& GetmQ(){return m_Q;}

qu'il faut implémenter la fonction ;) (une simple esperluette mal placée, et ca fout le boxon partout :D)

D'un autre coté (cela n'a rien à voir avec ton problème ;)), je présumes que la classe string que contient ton vector est bel et bien std::string :question:

Si oui, hormis le cas où les différentes chaines seraient gérées ailleurs et où ta classe NoeudSrcBruit servirait de "visiteur" (ou autre terme plus ou moins semblable) de ces chaines, tu aurait intérêt à faire en sorte que m_Q manipule... des chaines et non des pointeurs sur des chaines ;)

Enfin, le dernier conseil qui n'a rien à voir: tu devrait réfléchir à des noms plus explicite que m_Q et getmQ...

La première qualité d'un code, avant même de faire ce que l'on attend de lui, est d'être facilement compréhensible par la personne qui le lit, parce qu'il sera beaucoup plus souvent lu qu'écrit/modifié/compilé...

Si à la lecture de ton code, je me rend compte que:
- NoeudSrcBruit est le noeud d'un arbre
- que, visiblement, tu va travailler sur un arbre représentant des sons ou des images
- m_Q est une collection de chaines de caractères
je n'ai par contre aucune information sur ce que vont représenter les chaines collectées par m_Q... et c'est dommage ;)

Il serait peut être intéressant de réfléchir à un nom plus explicite pour ce membre, qui te permettra dans six mois, lorsque tu aura eu le temps d'oublier à quoi sert NodeSrcBruit (ou du moins les détails d'implémentation de cette classe), de te rappeler "facilement" l'utilité de m_Q ;)
26/02/2009, 11h37
loicounet

Merci des conseils,
pour les noms des variables, c'est ce qui arrive quand on reprend du code existant déjà: on ne se pose pas de questions!
26/02/2009, 12h01
koala01

Citation:

Envoyé par loicounet

Merci des conseils,
pour les noms des variables, c'est ce qui arrive quand on reprend du code existant déjà: on ne se pose pas de questions!

... ou, au contraire, on en pose tout plein, et on décide de se faciliter la vie en modifiant "le plus rapidement possible" ce qui est susceptible de nous la pourrir par la suite ;)

Si, à la première lecture d'un code (que tu ne connais pas), tu passe déjà 5 minutes à te "gratter la tête" en te demandant ce que représente un membre et ce à quoi il sert, tu peux raisonnablement penser que tu perdra les mêmes 5 minutes à te gratter la tête en te reposant les mêmes questions chaque fois que tu auras eu le malheur de laisser ton code "un peu trop longtemps" de coté...

Tu va peut être passer un temps certain à rechercher dans tout le code chaque instruction qui fait appel à ce membre et à le renommer en "quelque chose de compréhensible" (quoi que, avec les EDI actuels, c'est bien plus facile ;)), mais au final, tu gagnera 5 minutes chaques fois que tu devra reprendre le code après "un certain temps"...

Et ce qui est vrai pour les membres l'est pour les fonctions, qu'il s'agisse de les renommer ou de les commenter ;)

[EDIT]Ceci dit, je comprend qu'il y a des cas dans lesquels il est impossible de décider d'effectuer ses changements en profondeur...

Mais, à ce moment là, à défaut de renommer quelque chose, le simple fait de rajouter un petit commentaire fera déjà gagner pas mal de temps ;)