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) {}

[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
        }
};

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

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

[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;
}

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