Discussion :

[Luke spywoker]

Salut les C++,

j'ai plusieurs classes disposant de beaucoup de membres communs et d'une méthode commune: la méthode display(...).

J'ai donc fait une classe de base dont toutes les classes héritent mais le problème est que je n'arrive pas a surcharger la méthode display(...) correctement:

C'est la méthode display(...) de la classe parente qui est appeler lors de ce bout de pseudo-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
 
#include <vector>
 
#include "BaseClass.h"
 
#include "ClassDerived.h"
 
int main(int argc, char *argv[]) {
 
 
  std::vector<BaseClass> container ;
 
  for (int c=0 ; c < 1 ; c++) {
 
     ClassDerived instance(...) ;
 
     container.push_back(instance) ;
  }
 
  while (true) {
 
    int counter = 0 ;
 
    for (auto &instance : container) {
       instance.display() ; 
    }
 
  }
 
  return 0 ;
}

Alors comment définir la méthode display(...) dans la classe de base (BaseClass), dans le but que la méthode de la classe fille soit appeler ? A cause du conteneur.

Car j'aimerai pouvoir stocker mes objets de types différents dans un conteneur unique.

Je m'en sort pas avec tous ces mot-clefs (virtual, override, final, ...) au niveau de l'héritage.

Par ailleurs j'aimerai que mes attributs privée restent privée dans la classe héritée, sans que le compilateur s'en plaigne.

Alors quelle forme d'héritage utiliser: public, private ou protected ?

Merci pour vos lumière si vous comprenez le fond de ma question.

Merci pour vos réponses éclairées illuminant les ténèbres de ignorance.

[dalfab]

Bonjour,

Pour que les méthodes des descendants soient appelées, elles doivent être virtual.
Dans un container tous les objets doivent avoir le même type. Alors pour mettre des objets dont le point commun est le type de base, on doit mettre dans le containers des objets référençant le type de base. Le plus simple est d'utiliser des pointeurs.

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 Base {
public:
   virtual void display() {}
};
class Derive1 : public Base {
public:
   Derive1( int,int,int);
   void display() override {
      cout << "derivee #1";
   }
};
vector<unique_ptr<Base>> container;
container.push_back( make_unique<Derive1>( 1,2,3 ) );
container.push_back( make_unique<Derive2>() );
 
for ( auto &d : container )
   d->display();

[bacelar]

Autre remarque, partager du code n'est jamais un bon argument pour l'héritage autre que privé.
Et dans votre cas d'utilisation, vous ne pouvez pas utiliser l'héritage privé.
Je pense qu'il faire attention à votre conception et pas faire de l'héritage à tort et à travers.
L'héritage, c'est le truc à faire en dernier recourt.

[koala01]

Salut,

La première chose qui me choque, moi, c'est std::vector<BaseClass> container ; : si tu veux pouvoir utiliser des comportements polymorphes (comprend: des fonctions dont tu redéfinis le comportement au niveau des classes dérivées), tu dois:

1. définir les fonctions en question comme étant virutelles (mais ca, dalfab l'a déjà dit) et
2. accéder aux différentes instances des classes dérivées sous la forme de pointeur ou de référence et uniquement sous ces formes

Avec ton tableau destiné à revevoir des objets de type BaseClass, chaque fois que tu essaye de faire un push_back pour un élément dont le type est l'une des classes dérivées, tu observe un effet de slicing: tu n'ajoute en réalité que la partie correspondant à la classe de base de l'objet que tu essaye de rajouter dans ton tableau.

Du coup, il devient impossible d'observer le moindre comportement polymorphe, et c'est normal : les objets contenus dans ton tableau ne sont pas considérés comme étant du type dérivé mais... comme étant du type de base.

En outre, il faut savoir que toutes les fonctions de tous de tous les types de collection qui ont pour objectif d'ajouter un élément à la collection créent en réalité une copie de l'élément qu'elles ajoutent à la collection. Or, dés que tu décide de recourir à l'héritage publique entre deux classes, tu dois partir du principe que toutes les classes intervenant dans la hiérarchie de classes ont sémantique d'entité et qu'il devrait donc être impossible d'en faire une copie (et / ou d'affecter une instance à une autre, d'ailleurs)

La solution pour résoudre tous ces problèmes est relativement simple : il "suffit" de maintenir un pointeur sur les différents éléments du tableau plutôt que de maintenir l'objet en lui-même. Mais, pour éviter que le pointeur en question ne risque d'être "invalidé" lorsque l'on sort de la portée dans laquelle l'élément est réellement créé, il faudra sans doute passer par l'allocation dynamique de la mémoire, si bien que tu as sans doute intérêt à utiliser des pointeurs intelligents (std::unique_ptr, par exemple), afin d'éviter de foutre "trop le bordel" au niveau de la mémoire.
Au final, ton code devrait sans doute ressembler à quelque chose comme

Code :

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

1
2
3
4
5
6
7
8
9
int main(int arc, char ** argv){
    std::vector<std::unique_ptr<BaseClass>> tab;
    tab.emplace_back(std::make_unique<DerivedClass>(/* params éventuels */) );
    /* ... */
    for(auto const & it : tab){
        it.get()->draw();
    }
    return 0;
}

[Luke spywoker]

Merci les gars,

j'ai pu implémenter l'héritage de tous mes objets d'une classe de base Polyhedron.

Mais sous cette forme:

Code :

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

1
2
3
4
5
6
 
std::vector<Polyhedron*> polyhedrons ;
 
Sphere* polyhedron = new Sphere(...) ;
 
polyhedrons.push_back(polyhedron) ;

Car make_unique n'est pas définis dans la norme c++11...

[ternel]

Le remplacement de make_unique n'est pas new bidule, mais unique_ptr(new bidule).
un vecteur de pointeur nu n'indique pas qui doit détruire les pointés

d'un autre coté, make_unique se crée en quelques lignes, si on retire la forme pour les tableaux.

Code :

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

1
2
3
4
template< class T, class... Args >
unique_ptr<T> make_unique( Args&&... args ) {
    return unique_ptr<T>(new T(std::forward<Args>(args)...));
}

Une bonne partie de C++14 peut se reconstruire rapidement. D'ailleurs, le site cppreference.com donne souvent des implémentations possibles.

[Luke spywoker]

Salut les gars,

j'ai un nouveau problème d'héritage de classe de base.

Celui ci est analogue au premier c.a.d surcharger une méthode hérité mais cette fois la méthode hérité peut prendre n'importe quelle types d'arguments alors que le premier problème c'était les mêmes.

Je désire donc que ma classe de base implémente une méthode générique que l'on puisse override avec un méthode de la classe fille qui prendrai des arguments totalement différents selon la classe fille.

Est ce que cela est possible en c++ et si oui comment ?

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
 
 
class Base {
 
  public :
 
     virtual display(void) ; // No problem
 
     virtual reconfigure(...) ; // Here the problem
} ;
 
class Derived1 : public Base {
 
  public :
 
   void display(void) override ;
 
   void reconfigure(type1 arg1, type2, arg2, ...) override ;
} ;
 
class Derived2 : public Base {
 
  public:
 
   void display(void) override ;
 
   void reconfigure(type3 arg1, type4 arg2, ...) override ;
} ;

J'ai besoin de l'implémenter dans la classe de base pour pouvoir inclure mes classes filles dans un conteneur du type de la classe de base.

Merci pour vos réponses éclairées illuminant les ténèbres de mon ignorance.

[Bousk]

Non c'est pas possible. Si c'est pas les mêmes arguments, c'est pas la même signature et donc pas la même fonction.

[bacelar]

Et j'ai du mal à imaginer une conception objet qui aurait besoin de telles caractéristiques.

[Médinoc]

De plus, comment l'appellerais-tu?

[Luke spywoker]

Et bien en faîtes c'est une méthode

reconfigure(...)

qui prend les mêmes arguments que le constructeur de chaque objet dériver de Polyhedron et fait pratiquement la même chose: je régénère le buffer sans toucher a la position actuel grâce aux matrices dans la GPU...

Mais je pense m'en sortir grâce au constructeur de copie ?!?

[Médinoc]

Si tu peux appeler le constructeur de copie, alors tu connais le type. Donc, tu n'as pas besoin que ta méthode soit virtuelle.

[Luke spywoker]

Si parce que je désire placer des objets de types différents tous héritiers de la classe Polyhedron dans un conteneur de type Polyhedron justement...

[bacelar]

Bin non, parce que vous ne pouvez pas avoir des objets de type différents dans un conteneur.
Si vous voulez du polymorphisme, il faut passer par des pointeurs (de préférences intelligents).

Je ne comprends pas pourquoi reconfigure fait partie de la classe Polyhedron.
Si chaque sous-classe de Polyhedron à des arguments de constructeur différents:

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
 
class Base {
  public :
     virtual display(void) ; // No problem
} ;
 
class Derived1 : public Base {
  public :
   void display(void) override ;
} ;
 
class Derived2 : public Base {
  public:
   void display(void) override ;
} ;
 
Derived1 reconfigure(type1 arg1, type2 arg2, ...) {return Derived1(arg1,arg2,...);} ;
Derived2 reconfigure(type3 arg1, type4 arg2, ...) {return Derived2(arg1,arg2,...);} ;

Mais c'est toujours aussi abscons, car si vous avez des pointeurs sur Polyhedron dans un conteneur, c'est pour leur appliquer tous le même traitement, donc avec les mêmes arguments pour "reconfigure" (qui est un constructeur caché ???).