Discussion :

[ionnn]

Bonjour, j'ai le problème suivant : je crée une classe qui dérive de QObject, et j'aimerais redéfinir le constructeur de recopie ainsi que l'opérateur d'affectation. Or il se trouve qu'ils sont définit comme private dans QObject. Existe-t'il un moyen de résoudre ce problème ?

[Coelacanthe]

Excuse moi, je ne peux pas repondre à ta quéstion, enfin pas que je sache, je ne comprend pas bien ce qu'est un constructeur par recopie? Est ce qu'il s'agit d'une constructeur avec de quoi modifier tous les attribus de la classe en paramètre? En fait j'ai pas des vrai cours alors je connais pas les vrais tèrmes...

[PRomu@ld]

Si les méthodes sont vituelles tu devrai pouvoir (en tout cas de souvenir). Sinon, ça va poser peut être quelques soucis.

Mais dis moi si je me trompe (il y a longtemps que je n'ai pas fait de C++), si les membres sont privés, ils ne sont pas hérités, donc par conséquent pour ta classe fille, tu n'a pas à "redéfinir" le constructeur et l'opérateur d'affectation mais tu as à les définir (puisque qu'ils n'ont pas été hérités)

[hansaplast]

bein AMHA, soit tu modifie les sources pour les mettre en public, soit tu peut po...

a part si tu crée un constructeur en virtual et que tu appel ton propre constructeur, et celui de qt ensuite...

enfin, je debute plus que toi, donc c a prendre avec des pincettes...

[Laurent Gomila]

S'ils sont déclarés privés c'est certainement justement pour empêcher qu'on les définisse au niveau des classe filles. Il semble assez logique que des classes de contrôles ne puissent pas être copiables.

[ionnn]

Salut. Merci à ceux qui ont pris la peine de me répondre, même si en fait j'ai eu en retour plus de questions que de réponses Je vais essayer de répondre mais ne il ne faut pas prendre tous ce que je dis/écris pour parole d'évangile (en gros je ne suis pas hyper super mega sur de moi).

Coelacanthe : en fait un constructeur de copie/recopie (les deux termes s'emploient) sert à créer une copie d'un objet (un clone). Il est utilisé (entre autre) implicitement à chaque fois que tu passes ton objet comme paramètre d'une fonction.

Promu@ald : les membres private sont bien hérités (heureusement!), le seul problème c'est que tu n'y as pas accés, mais cela n'empêche pas de les redéfinir. Un petit exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
 
include <iostream>
 
class A
{      
 public:
 A(int v):valeur(v){};
 int getCarre();
 int valeur;
 
 private :      
 virtual int puissance(unsigned int);
 };
 
class B : public A
{
public :
B(int v):A(v){};
virtual int puissance(unsigned int);
};
 
int A::puissance(unsigned int n) 
{
if (n==0) return 1;
int result = valeur;
for (int i=1; i<n; ++i)
     result *= result;
return result;}
 
int B::puissance(unsigned int n)  
{
return valeur*n; 
}  
 
int A::getCarre()
{
return puissance(2);
}
 
int main()
{
A* a = new A(10);
B* b = new B(10);
std::cout<<a->getCarre()<<std::endl;
std::cout<<b->getCarre()<<std::endl;
return 0;
}

à l'exécution ce code va afficher :
>> 100
>> 20
donc il y a bien eu redéfinition de la méthode puissance(int) qui par contrecoup a affecté la méthode getCarre()...
Mais c'est vrai que l'on ne "redéfinit" pas un constucteur. En fait dans ma phrase originelle, redéfinir avez dans mon esprit le sens de "remplacer ceux fournis par défaut" . C'est je suppose une déformation professionnelle.

Hansaplast : modifié les sources m'a traversé l'esprit... et j'en ai mauvaise conscience! Pour le coup du constructeur virtual : j'ai pas tous compris.

Loulou24 : merci de m'avoir enlever les maigres espoirs que j'avais

[Fiquet]

modifié les sources m'a traversé l'esprit... et j'en ai mauvaise conscience! Pour le coup du constructeur virtual j'ai pas tous compris.

Normalement tu ne devrais jamais avoir à faire ça. Si ta bibliothèque est faite de telle manière, c'est que tu n'est sûrement pas sur le bon chemin. Je pense que pour ton problème tu dois pouvoir faire autrement non? Pourquoi aurais-tu besoin de le copier ou de le passer en paramètre d'une fonction?

Oublie le coup du constructeur virtuel. Un constructeur n'est jamais défini comme virtuel.

[JolyLoic]

Les objets dérivés de QObject sont des objets à sémentique d'entité, et non de valeur. Il est classique dans ces cas là que les objets soient non copiables, et destinés à être gérés pas des pointeurs.

Pour résoudre ton problème, sans en savoir plus j'hésite entre :
- Ton objet n'a pas en fait à être copiable
- Faire dériver ta classe de QObject, voilà l'erreur
- Tu peux créer dans ta classe une fonction createTwin qui créera un objet semblable au premier, mais différent (tu crées un nouvel objet, puis tu recopie les variables membres qui t'intéressent de l'un à l'autre, mais la partie héritée de QObject en particulier sera spécifique).

[Luc Hermitte]

Sans contournements à prévoir dès le début:
Héritage public => sémantique de référence => pas de copie possible, seul le clonage est envisageable avec un constructeur de recopie protégé et opérateur d'affectation interdit.

Si tu veux faire des copies,
- soit erreur de débutant (/non initié) que de croire qu'il faut toujours systématiquement définir constructeur de recopie et opérateur d'affectation -- cf d'ailleurs l'erreur de design dans tes deux classes A et B par rapport à la façon dont tu les manipules.
- soit ton problème doit être repensé. Es-tu réellement sûr que ton nouveau type est bien un sous type de QObject ? Que tu pourras toujours subtituer sans rompre aucun contrat (pré-, post-conditions, invariants, ...) un objet fils là où il est attendu un QObject ?

Il faudrait connaitre QT pour mieux voir ce que tu pourrais faire ici. Et probablement savoir pourquoi tu veux dériver un truc que tu pense devoir être copiable. Je passe la main à ceux qui le manipulent. Ne peux-tu partager tes objets plutôt que de provoquer des recopies profondes ?

[JolyLoic]

Oublie le coup du constructeur virtuel. Un constructeur n'est jamais défini comme virtuel.

Il existe un idiome dit du "constructeur par recopie virtuel", mais ce n'est pas un constructeur, mais une fonction clone. C'est généralement très utile quand on a une hiérarchie de classe, car un contructeur de recopie ne marche pas dans ce cas.

Dans ce cas précis, on ne peut pas utiliser cet idiome, mais ma fonction createTwin s'en approche.

[Fiquet]

Intéressant. C'est de ça dont tu parles ?

Car en fait si j'ai bien compris c'est impossible de faire une copie avec hiérarchie de classe grace à un constructeur de recopie "normal" ?

[JolyLoic]

Oui, c'est ça. Le problème d'un constructeur, c'est qu'on doit connaître le type exact de l'objet à construire. Dans une hiérarchie, ce n'est pas souvent le cas pour une copie d'objet, et l'on ne connaît l'objet que par un pointeur sur le type de base.

[Fiquet]

D'accord merci du renseignement .