Discussion :

[loicounet]

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:

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

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

[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.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
class NoeudSrcBruit : public NoeudData
{
protected:
 
	vector<string*>	m_Q;
public :
	vector<string*>& GetmQ(){return &m_Q;}

[koala01]

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

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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'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

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

[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!

[koala01]

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