Discussion :

[ymoreau]

Bonjour,
pour un projet d'université on nous a demandé de créer plusieurs classes qui héritent de conteneurs de la STL. Mais j'ai lu ensuite ici que ce n'était pas une bonne idée et qu'il valait mieux passer par une composition, sauf que tout mon code est déjà fait.

Le problème c'est que je me retrouve avec des erreurs franchement incompréhensibles alors que jusqu'ici tout fonctionnait bien. Pour résumer j'ai ces classes :

Code :

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

1
2
class Route : public std::list<int>
class Solution : public std::vector<Route>

Et j'ai des segmentation fault parfois dans une fonction toute simple parcourant la liste (dans Route), parfois dans les destructeurs de List et à l'instant même sur une simple affectation de valeur dans un int un peu plus loin (je suppose que gdb s'est embrouillé sur ce coup là).
Je précise que ça ne plante dés le début, ça boucle sur plusieurs fichiers et les premiers fonctionnent tout à fait. Je n'ai pas réussi à voir la différence de contexte.

Est-ce que quelqu'un aurait une piste de ce qui peut se passer ? est-ce que définitivement ces héritages sont imprévisibles et que je dois tout modifier pour une composition ?

Merci d'avance.

[ymoreau]

Bon finalement l'erreur venait de moi, je supprimais un objet dans un certain cas alors que je n'aurais pas dû. Du coup je suppose qu'ensuite un delete était appelé sur un pointeur déjà libéré, même si je trouve toujours étrange les erreurs que cela provoquait.

[3DArchi]

Salut,
Une classe devant servir de base à une héritage devrait avoir un destructeur virtuel s'il est public ou protégé s'il n'est pas virtuel comme l'explique cette entrée de la F.A.Q : Pourquoi le destructeur d'une classe de base doit être public et virtuel ou protégé et non virtuel ?
Le corolaire est que si une classe a un destructeur public non virtuel, alors elle ne doit pas être utilisée pour un héritage public. Ce qui est le cas des conteneurs de la STL.
La composition est alors souvent la solution employée pour utiliser les services de la classe.
Néanmoins, si ton projet impose l'utilisation de l'héritage, alors tu peux quand même t'en sortir 'proprement' avec une héritage privé. L'héritage privé permet de bénéficier de l'implémentation de la classe de base sans rajouter la sémantique EST-UN. Tu peux ensuite ramener les fonctions qui t'intéressent de la classe de base vers une visibilité publique dans la classe dérivée avec le mot-clé using :

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
#include <list>
 
class Route : private std::list<int>
{
   public:
   using std::list<int>::begin;
   using std::list<int>::end;
   using std::list<int>::push_back;
 
};
 
#include <iostream>
#include <iterator>
#include <algorithm>
int main()
{
   Route r;
   r.push_back(1);
   r.push_back(2);
   r.push_back(3);
   std::cout<<"Mes routes : \n";
   std::copy(
      r.begin(),
      r.end(),
      std::ostream_iterator<int>(std::cout,"\n")
   );
   return 0;
}

Ainsi, il n'est plus possible d'écrire le code suivant qui est un comportement indéfini sinon :

Code :

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

1
2
3
 
   std::list<int> *p = new Route; // erreur : cast impossible
   delete p;

[ymoreau]

Je ne connaissais pas using, merci beaucoup de cette réponse claire