Discussion :

[Rodrigue]

Bonsoir,

Je souhaiterais construire différents objets générants automatiquement des tableaux contenants des coordonnées de points (je simplifie).

Pour ce faire, j'ai créé une classe mère:

Code :

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

1
2
3
4
5
6
7
8
class MainA
{
public:
   MainA(int number_of_point); //constructeur
protected:
   virtual void Generate(/* ...*/)=0; //fct virtuelle responsable de la génération des différents points
   std::vector< std::pair<float, float> > array; //tableau de points
};

et des classes filles, dont en voici une pour l'exemple:

Code :

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

1
2
3
4
5
6
7
8
9
class ExpA
{
public:
   ExpA(int number_of_point): MainA(number_of_point) {;}
protected:
   void Generate(/* ...*/) {
      array.pushback(std::pair<float,float>(0.0f,3.14f);
      //...
   }

dans laquelle je définis la fonction virtuelle générale.

Le problème c'est que j'appelle la fonction virtuelle Generate depuis le constructeur de la classe mère...

Code :

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

1
2
3
MainA::MainA(int number_of_point) {
   Generate(/* ... */);
}

Pour moi ça ne pose pas de problème (bon je sais qu'il y en a un vu que ça crash )
La classe mère appelle sa fonction virtuelle au lieu d'appeller la fonction surchargée/définie de la classe fille:

Code :

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

ExpA a(10); //boom! Appel d'une fonction virtuelle

Il va de soi que je n'instancie jamais d'objet MainA vu qu'il s'agit d'une classe abstraite.

Je sais que la solution consiste à déplacer l'appel de la fonction Generate dans le constructeur de la classe fille (je suis fainénant ça m'énerve de devoir le réécrire à chaque fois)... mais bon je me demande quant même pourquoi il n'appelle pas la fonction surchargée ... (oui c'est parce qu'il est à l'intérieur de l'autre constructeur -> je trouve que ça ne fonctionne pas si bien que ça: on doit dupliquer plein de code).

Alors là, je me dis qu'une fonction de callback ça fonctionnerait qd même bien mais bon niveau simplicité y'a mieux!

Bonne soirée!

[Mat007]

Salut,

je me demande quant même pourquoi il n'appelle pas la fonction surchargée ...

Parce qu'au moment de l'appel l'objet de type ExpA n'existe pas encore.

Sinon il y a visiblement un problème de design, c'est le cas quand on rencontre ce genre de situation, en plus ici tu as des données protégées ce qui est un autre code smell un peu dans le même style...
Par exemple pourquoi pas plutôt une méthode MainA::Add pour ajouter les valeurs et appeler Generate (non virtuel du coup) depuis le constructeur de ExpA ?

MAT.

[koala01]

Salut,

Le constructeur fonctionne selon un ordre bien précis:

• Appel du constructeur de la classe mère, s'il y en a une
• Initialisation des membres dans l'ordre de leur déclaration
• appel des fonctions se trouvant dans le constructeur.

Evidemment, si tu parle d'un arbre d'héritage, tu entre dans une logique de "poupées russes": le constructeur de chaque classe appelant celui de la classe dont il hérite.

Seulement, voilà...

Si une classe fille sait très bien quelle est sa classe mère, une classe mère n'a aucun moyen de savoir quel est le type final de l'objet :

Ce peut être, simplement, la classe "en cours" (s'il ce n'est pas une classe abstraite) ou chacun des types qui en héritent, directement ou indirectement.

Du coup, tout appel à une méthode au sein du constructeur ne peut appliquer que les méthodes:

• définies au sein du type en cours de traîtement
• déjà définies au niveau de la classe mère

Fatalement, quand tu est au niveau de la racine de ton arbre d'héritage, et que tu appelle une méthode qui est alors virtuelle pure, la méthode... n'est pas implémentée, et le pointeur la concernant dans la vtable pointe sur l'adresse... 0 (ce n'est en définitive que la définition "de base" d'une méthode virtuelle pure )

Toute tentative d'appel à cette fonction ne peut que se solder par... un crash magistral

En outre, si tu utilise un arbre d'héritage à plusieurs niveaux, dont seule la classe racine est abstraite, tu risque de te trouver dans une situation complexe à gérer.

Pour t'en convaincre, voici un code 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
 
class A
{
    public:
        A(){}
        virtual~A(){}
        virtual void Function()=0;
    /*...*/
};
class B:public A
{
    public:
        B(){}
        virtual ~B(){}
        virtual void Function{/* do something for B type */}
};
class C:public B
{
    public:
        C(){}
        virtual ~C(){}
        virtual void Function{/* do something for C type */}
};
int main()
{
    C obj;//appel du constructeur de C
}

Tu peux souhaiter que le constructeur appelle function, en espérant qu'elle fasse ce qui est applicable au type réel.

Pour B, il n'y a pas de problème: Apres avoir appelé le constructeur de A et initialisé ses propres membres, on peut faire appel à Function, et tout roule

Par contre, pour C, c'est tout à fait différent:

Son constructeur appellera systématiquement celui de B... et provoquera l'appel de la version de Function sous son implémentation pour B, avant d'initialiser les membre de C, et d'effectuer ce qui se trouve dans le constructeur de C (qui peut lui-même, pourquoi pas, appeler la version de Function qui est propre à C).

Si c'est ce que tu attends comme fonctionnement, ben, tu es tout à fait libre de travailler ainsi, mais il n'y a aucun moyen de faire que seule la version propre à B ne soit appelée que on a bel et bien affaire à un objet de type B et que la version propre à C soit appelée si l'objet est de type C... Du moins, par appel dans le constructeur

[Rodrigue]

Parce qu'au moment de l'appel l'objet de type ExpA n'existe pas encore.

Sinon il y a visiblement un problème de design, c'est le cas quand on rencontre ce genre de situation, en plus ici tu as des données protégées ce qui est un autre code smell un peu dans le même style...
Par exemple pourquoi pas plutôt une méthode MainA::Add pour ajouter les valeurs et appeler Generate (non virtuel du coup) depuis le constructeur de ExpA ?MAT.

Oui, je sais mais comme je l'avais indiqué à la fin du message je suis fainéant

Je sais que la solution consiste à déplacer l'appel de la fonction Generate dans le constructeur de la classe fille (je suis fainénant ça m'énerve de devoir le réécrire à chaque fois)...

Sinon tu me conseilles quoi comme autre design?

J'ai une classe qui doit générer un tableau d'éléments en un coup (pas deux appels):

Code :

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

mFunction F(100);

Le seul paramètre à lui passer est un entier représentant la taille du tableau (un std::vector).

J'ai bien évidemment plusieurs fonctions différents... A chaque fois la seule chose qui change, c'est la méthode Function. Tu vas me dire que je pourrais mettre toutes ces fonctions dans la classe mère, elle même et en dériver d'autres classes filles qui passerait seulement un "switch"... Me fais-je bien comprendre?

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
48
49
50
51
52
53
enum SuperSwitch {F1, F2, F3}
class MainA
{
public:
	MainA(int n, SuperSwitch choice) 
		, _choice(choice)
	{
		data.resize(n);
 
		if(! Generate())
			throw;
	}
 
private:
	SuperSwitch _choice;
	std::vector<float> data;
 
	bool Generate(void)
	{
		switch(choice)
		{
		case F1:	for(int i=0; i<data.size(); i++)	data[i] = F1(i);	break;
		case F2:	for(int i=0; i<data.size(); i++)	data[i] = F1(i);	break;
		case F3:	for(int i=0; i<data.size(); i++)	data[i] = F1(i);	break;
 
		default: return false
		}
 
		return true;
	}
 
	float F1(float x)	{	return /* ... */;}
	float F2(float x)	{	return /* ... */;}
	float F3(float x)	{	return /* ... */;}
};
 
class MainF1: public MainA
{
public:
	MainF1(int n) : MainA(n, F1) {;}
};
 
class MainF2: public MainA
{
public:
	MainF2(int n) : MainA(n, F2) {;}
};
 
class MainF3: public MainA
{
public:
	MainF3(int n) : MainA(n, F3) {;}
};

[Rodrigue]

Salut,
Si une classe fille sait très bien quelle est sa classe mère, une classe mère n'a aucun moyen de savoir quel est le type final de l'objet :

Ce peut être, simplement, la classe "en cours" (s'il ce n'est pas une classe abstraite) ou chacun des types qui en héritent, directement ou indirectement.

Du coup, tout appel à une méthode au sein du constructeur ne peut appliquer que les méthodes:
définies au sein du type en cours de traîtement
déjà définies au niveau de la classe mère

Merci pour ton explication très claire !

Et toi comment t'y prendrais-tu pour implémenter ce que je souhaite faire?
Qu'est-ce qu'y serait le plus propre? Utiliser des pointeurs de fontion (fonction de callback) ça peut être élégant et bien fonctionner non?

[koala01]

Hé bien, tant qu'à faire, je rendrais les constructeurs et opérateurs d'affectation privés (ou en tout cas protégés), et la fonction generate statique et renvoyant une instance de l'objet créé prenant une forme sans doute fort proche de

Code :

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

1
2
3
4
5
6
7
 
Montype Montype::generate(/*...*/)
{
    Montype ret(/*...*/);/*créer une instance de l'objet */
    /*tout ce que doit faire generate */
    return ret;
}

De cette manière, au lieu de faire un

Code :

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

Montype obj(/*...*/)

on passerait à

Code :

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

Montype obj=Montype::generate(/*...*/);

J'envisagerais donc un peu les choses un peu comme s'il s'agissait d'un singleton, tout en supprimant ce qui est le plus embêtant dans l'histoire: le fait que l'instance est unique

[Mat007]

Là comme ça je pense que je ne mettrais sans doute pas d'héritage mais que je construirais l'une classe avec l'autre. Quant à savoir si c'est MainA qui demanderait à ExpA de lui remplir son vecteur ou si c'est ExpA qui ferait des ajouts sur MainA j'avoue que j'en sais trop rien à l'avance, surtout sans manipuler des cas réels en tant qu'utilisateur.
Peut-être qu'en mettant MainA template sur ExpA (avec du coup Generate statique) pourrait aussi donner quelque chose d'intéressant.

En tous cas j'évite au maximum les héritages quand je peux, en général ça permet de mieux séparer les fonctionnalités et c'est finalement plus souple.

MAT.