Discussion :

[ehmicky]

Bonjour à tous,

Avec deux classes Parent et Enfant, que je ne peux pas modifier (par exemple provenant d'une bibliothèque), si je définis une classe PetitEnfant, dérivée d'Enfant (et non de Parent), comment appeler, dans le constructor de PetitEnfant, le constructor de Parent (c'est-à-dire la classe parente de sa classe parente) ?
Par exemple (ce code ne marche pas, c'est pour montrer ce que je veux dire) :

Code :

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

1
2
3
4
5
6
7
class Parent {};
class Enfant : public Parent {};
class PetitEnfant : public Enfant
{
  public:
    PetitEnfant( void ) : Parent( argument ) {};
}

Merci beaucoup.

[koala01]

Salut,

Tu n'as pas à le faire, tout simplement

C'est au role du constructeur de l'enfant d'appeler le constructeur de son parent, et, si l'enfant n'a pas prévu de moyens de fournir des arguments à son parent de manière indirecte, tu dois uniquement faire appel aux moyens dont tu disposes


Il faut savoir que, dans l'ordre de construction d'un objet, il y a d'office construction du parent (en tout premier lieu), avec donc construction des membres du parent (dans l'ordre de leur déclaration !) puis construction des membres de l'enfant.

Cette logique est garantie par le standard, et tu peux d'ailleurs t'en assurer avec le simple code

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
 
class Base
{
    public:
        /* un constructeur sans argument */
        Base(): str("")
        {
            std::cout<<" Ctor de Base sans argument... str=\"\""<<std::endl;
        }
        /* mais il peut aussi accepter des arguments :D */
        Base(std::string const & str):str(str)
            std::cout<<" Ctor de Base avec argument... str="<<str<<std::endl;
        }
    private:
        std::string str;
};
class Derived : public Base
{
    public:
        Derived()/* l'appel du ctor sans argument est implicite */
        {
            std::cout<<"Ctor de Derived sans argument"<<std::endl;
        }
        Derived(std::string const & str):Base(str)
        {
            std::cout<<"Ctor de Derived sans argument"<<std::endl;
        }
};
 
class SubDerived : public Derived
{
    public:
        SubDerived ()/* l'appel du ctor sans argument est implicite */
        {
            std::cout<<"Ctor de SubDerived sans argument"<<std::endl;
        }
        SubDerived (std::string const & str):Base(str)
        {
            std::cout<<"Ctor de SubDerived sans argument"<<std::endl;
        }
};
int main()
{
    SubDerived d1; /* output :  Ctor de Base sans argument... str=""
                     *          Ctor de Derived sans argument
                     *          Ctor de SubDerived sans argument
                     */
    SubDerived d2("salut"); /* output :  Ctor de Base sans argument... str=salut
                             *           Ctor de Derived sans argument
                             *           Ctor de SubDerived sans argument
                             */
    return 0;
}

CQFD

[ehmicky]

Merci pour ta réponse,

Ok, donc si je ressens vraiment le besoin d'utiliser le constructor de Parent, tout en souhaitant continuer à profiter des méthodes proposées par Enfant, c'est que la bibliothèque a été mal pensée, c'est bien ça ?
C'est un peu frustrant, mais je comprends la logique sous-jacente. Merci beaucoup !

[koala01]

Ce qu'il faut comprendre, c'est que le constructeur ne sert qu'à une et une seule chose : construire l'objet au moment où l'on demande une instance de la classe, et l'initialiser afin de profiter du RAII (Ressource Acquisition Is Initialization)

Cela peut, éventuellement, se faire en appelant une fonction membre de l'objet (attention : pas de polymorphisme disponible ici ) qui puet, pourquoi pas, etre publique ou protégée pour etre disponible "depuis n'importe où" pour une fonction membre publique ou depuis "les classes dérivées" dans le cas d'une fonction membre protégée.

Il faut aussi comprendre que l'héritage public est une relation EST-UN, et que c'est pour cela que le constructeur de la classe parent est appelé avant meme d'appeler le constructeur des membres de la classe dérviée : tu ne peux pas construire un objet de type Voiture si tu n'as pas construit, à la base, un objet de type Vehicule

[3DArchi]

Salut,

Merci pour ta réponse,

Ok, donc si je ressens vraiment le besoin d'utiliser le constructor de Parent, tout en souhaitant continuer à profiter des méthodes proposées par Enfant, c'est que la bibliothèque a été mal pensée, c'est bien ça ?

C'est possible. Peux tu être un peu plus concret sur l'exemple. Logiquement, le constructeur doit te proposer un objet prêt à l'emploi (et éviter la nécessité de fonctions types initialize). L'héritage de parent par enfant ne doit en rien changer cette contrainte. Le jeu de paramètre du constructeur d'enfant peut être différent de celui de parent, mais au final tu dois avoir un objet disponible pour une utilisation.

[ehmicky]

Le problème précis concernait Gtkmm, avec la classe Gtk::FileChooserDialog ne permettant pas de définir la fenêtre comme une popup modale, contrairement à sa parente Gtk::Dialog.
Après, de toute façon, les popup modales, "c'est mal", et je pense que les développeurs de Gtkmm ou GTK+ ont considéré qu'une fenêtre de sélection de fichier ne devait jamais être modale, et j'imagine que je peux réussir à avoir le même effets via les méthodes héritées de Gtk::Window, mais je trouvais ça dommage d'enlever la possibilité.

[koala01]

Si tu veux rendre modale une fenêtre (héritant de) Gtk::FileChooserDialog qui n'est pas modale à la base, tournes toi peut être vers les fonctions membres publique de cette classe (ou de ses ancêtres) pour y trouver quelque chose qui ressemblerait à setNodal... Si la classe Gtk:: Dialog en dispose, je serais surpris qu'elle soit devenue inaccessible "comme par magie" (vérifiacation faite, c'est la class Gtk::Window, dont hérite Gtk:: Dialog qui en dispose, et elle est donc normalement accessible à tous ses descendants )

Le constructeur de ta classe dérivée prendrait alors "simplement" la forme de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class MYSpecialFileChoserDialog : public Gtk::FileChooserDialog 
{
    public:
       MYSpecialFileChoserDialog(Gtk::Window& parent, 
                                 const Glib::ustring& title, 
                                 FileChooserAction action=FILE_CHOOSER_ACTION_OPEN):
           FileChooserDialog(parent, title, action)
    {
        setModal();
    }
};

Tout bête, tout simple, très efficace

[3DArchi]

Le problème précis concernait Gtkmm, avec la classe Gtk::FileChooserDialog ne permettant pas de définir la fenêtre comme une popup modale, contrairement à sa parente Gtk:ialog.
Après, de toute façon, les popup modales, "c'est mal", et je pense que les développeurs de Gtkmm ou GTK+ ont considéré qu'une fenêtre de sélection de fichier ne devait jamais être modale, et j'imagine que je peux réussir à avoir le même effets via les méthodes héritées de Gtk::Window, mais je trouvais ça dommage d'enlever la possibilité.

Je ne connais pas plus que ça Gtkmm. En revanche, les bibliothèques IHM font souvent souffrir les principes d'un bon design. La, je pense qu'il s'agit simplement d'avoir un constructeur simple et pertinent par rapport à la classe en train d'être construite. L'objet est de toute façon prêt à être utilisé à l'issu de sa construction, donc tout va bien. Il ne te reste plus qu'à utiliser les fonctions membres, comme le dit koala, pour 'tunner' ton objet correctement. Remarque que s'il s'agit juste de la rendre modale, nul besoin d'en faire une classe dérivée car tu ne pourras maintenir cette propriété vrai tout le long. Instancies directement Gtk::FileChooserDialog et utilises la fonction adéquate (gtk_dialog_run() ?).

[ehmicky]

Ok, merci beaucoup !