Discussion :

[poukill]

Bonjour à tous,

J'aimerai juste un éclaircissement sur un point:
Quand on défini une classe abstraite, la classe possède alors au moins une méthode virtuelle pure.
S'il arrive que la classe représente purement et simplement une abstraction de donnée, alors il se peut qu'elle ne possède que des méthodes virtuelles pures...

Exemple pour moi d'une caméra, qui peut être une caméra infrarouge, visible, etc...
J'introduis donc une classe mère abstraite Camera.

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 Camera
{
public:
    Camera();
    virtual void getImage(int numero_image) = 0;
 
protected:
    virtual void initialisation() = 0;
    virtual void prepareCapture() = 0;
 
};
 
Camera::Camera()
{
    initialisation();
    prepareCapture();
}

Cette façon de faire permettrait aux classe dérivées de tranquillement redéfinir les deux méthodes virtuelles pures privées, et donc:

Code :

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

1
2
3
4
5
Camera_Visible::Camera_Visible()
:Camera()
{
    std::cout << "Pas besoin de plus !!" << std::endl;
}

suffirait amplement...

Je sais pas vraiment pourquoi ce n'est pas possible, mais c'est bien dommage car ce serait pratique.
Y a t-il une autre méthode à part définir des fonctions virtuelles à la place de fonctions virtuelles pures???

Merci !

[Bakura]

Code :

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

1
2
3
4
5
Camera_Visible::Camera_Visible()
:Camera()
{
    std::cout << "Pas besoin de plus !!" << std::endl;
}

Ben à partir de ce moment, tu appelles le constructeur de Camera qui tente d'appeler deux fonctions virtuelles pures, donc forcément ça plante .

Donc ce que tu peux faire c'est faire en sorte que initialisation et prepareCapture ne soient pas pures (mais tu peux laisser getImage pure, ainsi tu pourras pas instancier un objet de type Camera).

Je ne vois pas d'autres méthodes, je vais réfléchir voir si on peut faire ça avec des templates peut-être .

[Davidbrcz]

Dans ton exemple tu peux faire :

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
 
class Camera
{
public:
    virtual void getImage(int numero_image) ;
 
protected:
 
    Camera();
    Camera(Camera &obj);
    Camera operator = (const Camera &obj);
    ~Camera();
 
    virtual void initialisation() ;
    virtual void prepareCapture() ;
 
};
 
Camera::Camera()
{
    initialisation();
    prepareCapture();
}
 
Camera_Visible::Camera_Visible()
:Camera()
{
    std::cout << "Pas besoin de plus !!" << std::endl;
}

En effet , ici ta classe est abstraite et sans passer par les virtuelle pure .
Je ne connais pas un seul moyen de l'instancier.

[Jean-Marc.Bourguet]

Pendant l'exécution d'un constructeur comme d'un destructeur, le type dynamique est celui de l'objet construit. Donc l'appel à une fonction virtuelle n'utilise pas le type le plus dérivé et ce que tu veux faire ne fonctionne pas.

La raison est est simple: à ce moment, les membres du type le plus dérivé n'ont pas été construit. Un appel comme tu le désirerais pourrait accéder à des objets non construits, ce qui serait plutôt bizarre.

Deux manière de t'en sortir: une fonction d'initialisation à appeler après le constructeur et un paramètre supplémentaire au constructeur indiquant ce qui est à faire (par exemple avec des fonctions virtuelles...) 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
struct Initializer {
   virtual void init();
};
 
struct M {
   M(Initializer const& i) {
      i.init();
   }
};
 
struct F2Initializer: Initializer {
   void init();
};
 
struct F1: M {
   F() : F(FInitializer()) {}
};

L'utilisation de l'héritage multiple permet de faire des choses proches de ce que tu voulais:

Code :

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

1
2
3
4
5
6
7
struct F2Initializer: Initializer {
   void init();
};
 
struct F2: F2Initializer, M {
   F2(): F(*this) {}
};

[poukill]

Ok oui bien sûr...
Que ça ne marchait pas je savais, mais je n'avais pas fondamentalement compris comment ça marchait...

La raison est est simple: à ce moment, les membres du type le plus dérivé n'ont pas été construit. Un appel comme tu le désirerais pourrait accéder à des objets non construits, ce qui serait plutôt bizarre.

Mais alors, mettre des fonctions virtuelles non pures dans le constructeur de la classe mère ne marcherait pas non plus alors? Puisque l'objet dérivé n'est pas construit encore...
C'est bien ça?

[Laurent Gomila]

Mais alors, mettre des fonctions virtuelles non pures dans le constructeur de la classe mère ne marcherait pas non plus alors? Puisque l'objet dérivé n'est pas construit encore...

Ca fonctionnera, mais ce sont les fonctions de la classe en cours de construction qui seront appelées, même si elles sont surdéfinies.

[bafman]

de toute façon, en C++, appeler des fonction virtuelles dans un constructeur ou un destructeur, c'est généralement une erreure (à moins de bien savoir ce qu'on fait).

une fois qu'on connait cette regle, on evite bien des problèmes (surtout quand on vient de Java ou de c# qui ne gerent pas la chose de la même façon)

[poukill]

Ca fonctionnera, mais ce sont les fonctions de la classe en cours de construction qui seront appelées, même si elles sont surdéfinies.

D'accord bien sur...
Donc une simple déclaration :

Code :

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

1
2
3
class Camera {
    virtual void initialisation();
}

n'appelera pas la méthode de la classe fille dans le constructeur...
Partout ailleurs oui, mais pas dans le constructeur ni le destructeur...

Ok ça marche.

de toute façon, en C++, appeler des fonction virtuelles dans un constructeur ou un destructeur, c'est généralement une erreure (à moins de bien savoir ce qu'on fait).

Oui mais là j'ai une structure commune à chaque fois. Je voulais donc définir des directives générales dans le constructeur, et les classes filles n'ont qu'a implémenter leur spécificités pour se construire.

Bon, c'était peut etre pas une si bonne idée que ça !