Discussion :

[Rocknacro]

Bonjour,

Voilà mon contexte :

Une classe A ayant pour constructeur :

Code :

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

A::A(int a) { this->a = a }

Une classe B héritant de A ayant deux constructeurs :

Code :

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

1
2
B::B() { B(0) } // appel du constructeur avec un paramètre entier
B::B(int a) : A(a) { } // appel au constructeur de la classe parent

Comme vous avez pu le constater ce que j'aimerais c'est que si j'instancie mon objet B sans paramètre, celui-ci appel le constructeur avec un paramètre (0 en l'occurance).
Donc ça ça joue bien, pas de problèmes, mais j'aimerais évidemment que ma classe B appel le constructeur A lors de l'instanciation.

Et de la manière dans laquelle je l'ai présenté ci-dessus ça ne marche pas. Compilation + Linking ok, mais erreur de segmentation lors de l'exécution.

Mon main ressemble donc à celà :

Code :

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

1
2
3
int main(void) {
A* objet = new B();
}

Merci d'avance de votre aide future.

[AF_2.8]

Le plus simple est de déclaré un constructeur dans B avec paramètre optionnel :

Code :

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

B(int a=0);

Code :

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

B::B(int a) : A(a) {}

[koala01]

Bonjour,

Voilà mon contexte :

Une classe A ayant pour constructeur :

Code :

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

A::A(int a) { this->a = a }

Très mauvaise idée...

Il vaut toujours mieux utiliser les listes d'initialisation

Une classe B héritant de A ayant deux constructeurs :

Code :

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

1
2
B::B() { B(0) } // appel du constructeur avec un paramètre entier
B::B(int a) : A(a) { } // appel au constructeur de la classe parent

On n'appelle JAMAIS le constructeur d'une classe dans un autre constructeur de la même classe !!!!

Par contre, comme c'est le constructeur de A qui t'intéresse, tu peux invoquer explicitement celui-ci dans la liste d'initialisation, en lui passant les valeurs ad-hoc:

Code :

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

1
2
3
4
//pour le constructeur par défaut de B
B::B():A(0){}
// pour le constructeur de B prenant un int
B::B(int i) : A(i){}

Donc ça ça joue bien, pas de problèmes, mais j'aimerais évidemment que ma classe B appel le constructeur A lors de l'instanciation.

Tu ne peux pas l'éviter, vu que B hérite de A et donc que B EST UN A...

Comme la base de B est A, il faut absolument s'asusrer que la partie de B qui vient de A soit correctement initialisée, sinon, tu va avoir des problèmes

Et de la manière dans laquelle je l'ai présenté ci-dessus ça ne marche pas. Compilation + Linking ok, mais erreur de segmentation lors de l'exécution.

Et pour cause...

[3DArchi]

Bonjour,
En C++0x, tu peux enchaîner les constructeurs comme suit :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
struct A
{
   A(int a_):a(a_){}
private:
   int a;
};
struct B : public A
{
   B():B(0){}
   B(int a):A(a){}
};

Mais mieux, en C++0x tu peux aussi hériter des constructeurs des classes de bases :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
struct A
{
   A(int a_):a(a_){}
private:
   int a;
};
struct B : public A
{
   using A::A; // et hop, tu as naturellement un constructeur B(int) qui appelle directement A(int) !!!
};

LE hic ? C'est qu'aujourd'hui la délégation et l'héritage de constructeur ne sont pas encore disponibles sur les compilateurs Visual ou GCC

Et en C++98, ce n'est pas possible d'enchaîner les constructeurs ou d'en hériter. Il te faut donc soit passer par une fonction d'initialisation dédiée si le nombre de paramètres et le contenu des constructeurs étaient complexe, soit simplement écrire à la main :

Code :

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

1
2
B::B():A(0) { } // appel du constructeur avec un paramètre entier
B::B(int a) : A(a) { }

P.S. : Pourquoi une allocation dynamique ? Réflexe Java/C# ?

Code :

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

1
2
3
4
5
6
7
8
int main(void)
{
   B b;
   A& objet = b;
 
 
   return 0;
}

[3DArchi]

Le plus simple est de déclaré un constructeur dans B avec paramètre optionnel :

Code :

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

B(int a=0);

Code :

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

B::B(int a) : A(a) {}

Je n'ai jamais beaucoup aimé des paramètres optionnels mais c'est probablement une question de goût.
Bref, tout ceci pour dire qu'en lisant cette réponse cela m'a fait penser que si ton constructeur n'a qu'un seul paramètre (optionnel ou pas) pense à le déclarer explicit pour éviter des comportements inattendus :

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
struct A
{
    protected:
   A(int a_):a(a_){}
   ~A(){}
 
private:
   int a;
};
 
struct B : public A
{
   B(int a_=0):A(a_){}
};
 
struct C : public A
{
   explicit C(int a_=0):A(a_){}
};
 
 
void fonction1(B){}
void fonction2(C){}
int main()
{
    fonction1(1);  // convertit 1 en B(1). Est-ce vraiment voulu ???
    fonction2(1); // erreur
    fonction2(static_cast<C>(1));
    return 1;
}

[Rocknacro]

Ce que je n'ai pas précisé, c'est que dans mon constructeur "principal" je fais beaucoup d'autres opérations.

En faisant

Code :

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

B::B() { B(0) }

Cela me permettait de placer toutes mes instructions uniquement dans le constructeur avec paramètre B::B(int a).

Sinon oui effectivement, l'allocation dynamique est un réflexe Java... La manière présenté ci-dessus y est d'ailleurs assez courante en Java.

EDIT: pour le constructeur explicite, c'est justement l'implémentation du polymorphisme qui m'intéresse ici, mais merci de l'info

[koala01]

Ce que je n'ai pas précisé, c'est que dans mon constructeur "principal" je fais beaucoup d'autres opérations.

En faisant

Code :

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

B::B() { B(0) }

Cela me permettait de placer toutes mes instructions uniquement dans le constructeur avec paramètre B::B(int a).

Sinon oui effectivement, l'allocation dynamique est un réflexe Java... La manière présenté ci-dessus y est d'ailleurs assez courante en Java.

Dans ce cas, tu factorise ton code dans une fonction qui va faire les autres opérations, et tu invoque cette fonction dans ton constructeur:

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
class B : public A
{
     public:
         B():A(0)
         {
             doManyOtherThinks();
         }
         B(int i):A(i)
         {
             doManyOtherThinks();
         }
    private:
        void doManyOtherThinks()
        {
            // what you want
        }
};

[3DArchi]

EDIT: pour le constructeur explicite, c'est justement l'implémentation du polymorphisme qui m'intéresse ici, mais merci de l'info

explicit c'est par rapport au polymorphisme de coercition qui peut avoir sur int pas par rapport au polymorphisme d'inclusion lié à l'héritage.

[Rocknacro]

Dans ce cas, tu factorise ton code dans une fonction qui va faire les autres opérations, et tu invoque cette fonction dans ton constructeur:

Ok c'est fait, ça me plaît pas trop j'aurais préféré tout faire dans un seul constructeur (refactoring ou pas) mais ça marche comme ça.

Merci à tous pour vos remarques intéressantes.

[koala01]

Ok c'est fait, ça me plaît pas trop j'aurais préféré tout faire dans un seul constructeur (refactoring ou pas) mais ça marche comme ça.

Merci à tous pour vos remarques intéressantes.

Pourquoi donc est-ce que cela ne te plait pas trop

Une saine pratique à veiller à mettre en oeuvre est de veiller à ne pas se répéter soi-même: si tu dois écrire un code plus d'une fois, c'est (souvent) que tu dois l'écrire trop souvent et donc qu'il est intéressant de créer une fonction qui s'occupera exclusivement de cette tâche.

Comme on ne peut (du moins avec la norme en vigueur, car C++11x n'est pas encore ni finalisé, ni complètement supporté), pas appeler un constructeur depuis un autre constructeur de la même classe, on n'a pas vraiment d'autre choix

Tu dois simplement faire attention au fait que tu ne peux pas espérer invoquer un comportement polymorphe, car le type (dynamique) d'un objet au moment du constructeur est... le type pour lequel le constructeur est invoqué .

[Arzar]

LE hic ? C'est qu'aujourd'hui la délégation et l'héritage de constructeur ne sont pas encore disponibles sur les compilateurs Visual ou GCC

Pour info, la délégation de constructeur est présent sous clang depuis quelques jours.

[Rocknacro]

Comme on ne peut (du moins avec la norme en vigueur, car C++11x n'est pas encore ni finalisé, ni complètement supporté), pas appeler un constructeur depuis un autre constructeur de la même classe, on n'a pas vraiment d'autre choix

... Voilà pourquoi ça ne me "plait pas trop", car je suis habitué au monde Java. Mais effectivement la méthode ainsi appliquée, diviser pour régner, résout très bien le problème et enlève toute redondance à mon code.

[koala01]

... Voilà pourquoi ça ne me "plait pas trop", car je suis habitué au monde Java. Mais effectivement la méthode ainsi appliquée, diviser pour régner, résout très bien le problème et enlève toute redondance à mon code.

Primo, nous ne sommes pas sous java, mais sous C++, et, secundo, pose toi peut être simplement la question de savoir ce qu'est un constructeur...:

Ce n'est jamais qu'une fonction membre (comme n'importe quelle autre) qui a une responsabilité clairement définie : faire en sorte de fournir un objet correctement initialisé au moment où l'on a besoin de l'objet.

A partir de là, je ne vois pas ce qu'il y a de mal à, tout comme dans n'importe quelle autre fonction, décider d'invoquer une fonction qui prend en charge une partie (clairement définie) de ce que l'on en attend

Il faut juste faire attention aux éventuels problèms liés à la virtualité des fonctions appelées, car, dans tous les cas, le type envisagé lors de l'appel d'une éventuelle fonction virtuelle ne sera que celui du type en cours de construction (c'est à dire de la classe mère et non de la classe dérivée si l'appel de la fonction se fait dans le constructeur de la classe mère )

[gl]

A partir de là, je ne vois pas ce qu'il y a de mal à, tout comme dans n'importe quelle autre fonction, décider d'invoquer une fonction qui prend en charge une partie (clairement définie) de ce que l'on en attend

De mal, absolument rien.

Mais il faut admettre que lorsque cette fameuse fonction correspond à un des constructeurs, c'est juste pénible de devoir la faire. En ce sens la délégation de constructeur n'est certes pas quelque chose d'indispensable mais c'est un sucre malgré tout bien sympathique.

[koala01]

De mal, absolument rien.

Mais il faut admettre que lorsque cette fameuse fonction correspond à un des constructeurs, c'est juste pénible de devoir la faire. En ce sens la délégation de constructeur n'est certes pas quelque chose d'indispensable mais c'est un sucre malgré tout bien sympathique.

Je n'ai jamais dit que ce n'était pas sympathique, j'ai juste dit que... c'est un sucre, tout sympathique soit il

Ma remarque ne portait pas sur le "est-ce sympa de pouvoir déléguer le constructeur" mais plutôt sur ce que j'ai ressenti comme une envie réellement profonde de ne pas simplement déléguer la tâche à une fonction séparée