Discussion :

[pythagor]

Bonjour et bonne année à tous

Je débute en C++ (mais j'ai de bonnes connaissances en Java)

Je bloque sur un exercice qui n'a pas l'air difficile:

voici le contexte :
Je dispose d'une classe abstraite Vehicule et de deux sous classes Voiture et Moto.

Voici la question

Creez une nouvelle classe Garage contenant des vehicules (moto+voitures)

Il faudra se servir de la classe template list< >
Il y a deux façons de proceder (mais vous ferez la deuxième méthode)

1) le plus simple serait de créer une classe garage possédant une liste de vehicules (comme instance)

Cette méthode est la plus simple mais vous devrez définir toutes les méthodes servant à la gestion d'une liste de véhicules (ajout, suppression , tri en fonction de l'immatriculation , tri en fonction du nom de propriétaire...)

2) vous pouvez aussi créer une classe garage qui devra hériter d'une liste de véhicules (la liste est alors héritée de la classe parente)

Cette méthode est plus rapide car vous heriterez des méthodes déjà implémentées de list

Il vous est demandé d'utiliser la deuxième méthode !

Je trouve la première méthode assez simple (je vois bien comment faire)
Cependant pour la seconde je suis un peu coincé sur la synthaxe:

Si j'ai bien compris ma classe garage sera une sous classe de list<Vehicule>
J'ai essayé un bon nombre de syntaxes differentes telles que

Code :

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

1
2
3
4
5
6
 
class Garage<Vehicule> : list<Vehicule>
 
class Garage : list<Vehicule>
 
class Garage<Vehicule> : list

mais rien ne compile

Auriez vous une petite idée?

Merci beaucoup

[Bousk]

Salut,

je dirais surtout que les énoncés sont au mieux évasifs, inducteur d'erreurs, si ce n'est carrément faux.
Vehicule est abstraite, tu ne peux pas avoir un std::list<Vehicule>
Tu pourras avoir tout au mieux un std::list<Vehicule*>. A vrai dire tu pourras avoir que ça.

Je suppose que ce qu'il attend c'est un class Garage : public std::list<Vehicule*> {};. Rien ne l'interdit, faut juste être conscient que std::list n'a pas de destructeur virtuel.
Mais bon c'est un peu naze, autant avoir un simple typedef/using à ce niveau.

une liste de vehicules (comme instance)

Je suppose qu'il voulait dire "comme membre". Vraiment mal écrit cet énoncé..

[dalfab]

Ou pour résoudre l’absence de destructeur virtuel, on peut aussi utiliser class Garage : public std::list<std::shared_ptr<Vehicule>> {};

[pythagor]

Merci beaucoup

Effectivement j'aurais fait d'emblée la première méthode ^^
Je vais tenter ce que vous dites et je verrai comment m'en sortir

[Bousk]

Ou pour résoudre l’absence de destructeur virtuel, on peut aussi utiliser class Garage : public std::list<std::shared_ptr<Vehicule>> {};

Je vois pas trop ce que tu espères résoudre comme "problème d'héritage sans destructeur virtuel" avec ça

[Iradrille]

@ Bousk, il est peut être question d'héritage privé ici ? Enfin pour moi "hériter de la STL" et "héritage privé" sont quasiment synonymes.

Maintenant est-ce-que l'héritage privé a un réel avantage par rapport à l'agrégation ici ? Je pense pas, c'est une façon de penser plus Java (encore qu'en Java on aurait un héritage publique) que C++ : en Java / C# on privilégie l'héritage, en C++ on privilégie l'agrégation.

[dalfab]

Je vois pas trop ce que tu espères résoudre comme "problème d'héritage sans destructeur virtuel" avec ça

La destruction de la liste va automatiquement détruire tous ses éléments et libérera proprement tous les shared_ptr donc tous les Vehicule qui eux doivent avoir un destructeur virtual.
Alors qu'en utilisant une liste de pointeurs, on aurait besoin d'intercepter la destruction de liste dans ce cas pour libérer les Vehicule.

[Bousk]

La destruction de la liste va automatiquement détruire tous ses éléments et libérera proprement tous les shared_ptr donc tous les Vehicule qui eux doivent avoir un destructeur virtual.
Alors qu'en utilisant une liste de pointeurs, on aurait besoin d'intercepter la destruction de liste dans ce cas pour libérer les Vehicule.

Merci je sais à quoi sert le shared_ptr... Mais ça n'a toujours rien à voir avec le problème de l'absence de destructeur virtuel sur std::vector.

@ Bousk, il est peut être question d'héritage privé ici ? Enfin pour moi "hériter de la STL" et "héritage privé" sont quasiment synonymes.

Dans le cadre d'un cours, je pense pas. L'héritage privé est si peu utilisé en pratique, je n'ai jamais embêté mes étudiants avec ça perso. Comme l'héritage protected, 1 slide, 5mn pour dire "ça existe et ça sert à rien", on passe à la suite qui est utile.
Hériter de la STL n'a rien de sorcier ou maudit, il suffit de ne jamais allouer dynamiquement le conteneur et le manipuler en tant que classe de base lors de sa destruction. En pratique encore je n'ai jamais rencontré de new MyVector où MyVector dérive de std::vector.
L'intérêt de dériver de std::vector c'est d'avoir une interface simple déjà faîte, et d'y ajouter quelques trucs qu'on trouve utile. Si on veut pas juste manipuler un vector et avoir les fonctions de manipulation externe, ce qui revient dans 99% des cas au même.

[pythagor]

je vois que cette question suscite un petit débat

Par contre je comprends rien au débat

[koala01]

Salut, et bonne année

La destruction de la liste va automatiquement détruire tous ses éléments et libérera proprement tous les shared_ptr donc tous les Vehicule qui eux doivent avoir un destructeur virtual.
Alors qu'en utilisant une liste de pointeurs, on aurait besoin d'intercepter la destruction de liste dans ce cas pour libérer les Vehicule.

Le problème, ce n'est pas le fait que la destruction de la liste occasionne la destruction des véhicules qu'elle contient, mais c'est que si Garage hérite de std::list, on peut -- en vertu du LSP -- décider de ne connaitre une instance de type Garage que comme étant (un pointeur sur) une instance de type std::list, et donc envisager d'avoir un code qui ressemblerait à

Code :

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

1
2
3
4
5
6
7
8
9
10
 
class Garage : public std::list<std::unique_ptr<Vehicule>>{
    /* ...*/ 
};
int main(){
    std::list<std::unique_ptr<Vehicule>>  * g = new Garage;
    /* ... */
    delete g;
    return 0;
}

Or, le fait que le destructeur de std::list ne soit pas virtuel présentera un très sérieux problème : lors de l'appel à delete g;, seul le composant "std::list<std::unique_ptr<Vehicule>>" de notre classe Garage sera détruit -- alors que l'on serait en droit de s'attendre à ce que tout ce qui fait partie de la classe Garage le soit -- ce qui pourrait occasionner de très sérieux problèmes par la suite (même si mon exemple ici est suffisamment simple pour les éviter sur la plupart des architectures actuelles).

Alors, il est vrai que, avec la classe Garage que je présente, un code proche de

Code :

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

1
2
3
4
5
int main(){
    Garage g;
    /* ... */
    return 0;
}

ne posera absolument aucun problème, vu que l'on connait notre garage comme étant... un garage. Mais, comme l'héritage public est destiné à nous permettre de substituer un élément du type dérivé partout où l'on s'attend à obtenir un élément du type de base, on ne peut tout simplement pas prendre le risque que l'utilisateur de notre type Garage ne soit tenté de travailler avec un (pointeur ou une référence sur un) objet qu'il connait comme étant de type std::list.

Car il ne faut pas oublier la loi de Murphy : si tu laisses la possibilité à quelqu'un de faire une connerie, tu dois t'attendre à ce qu'il la commette forcément tot ou tard, et ce sera toujours au pire moment possible.

Dés lors, la règle de base est : on ne fait JAMAIS dériver (publiquement) une de nos classes personnelles d'une collection proposée par la bibliothèque standard!

Certains seront sans doute tentés de trouver des exceptions à cette règle (après tout, chaque règle a ses exceptions, non ) mais aucune exception ne sera admise pour la cause face à cette règle, qui doit être gravée dans le marbre

[dalfab]

@Koala, je suis tout à fait d'accord, j'étais peut-être un peu trop dans l'idée d'une classe basée sur un postulat que la classe garage n'ajoutait absolument rien à la la liste de véhicules,
ce qui passerait pour un exercice mais n'est évidement pas du tout pérenne pour une 'vraie' application

[ternel]

Si le garage n'ajoute rien à la liste, utilise un using (voire un vieux typdef).
Sinon, le conseil de Koala01 est le bon: inclure une liste dans la classe, par composition

[Iradrille]

J'en profite pour poser une question.

Est-ce correct ?

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
typedef std::list<Vehicule*> list_t;
 
struct Foo : public list_t {
   int i;
};
 
struct Bar : public list_t {
   Bar() : ptr(new int[42]) { }
   ~Bar() { delete[] ptr; }
 
   int *ptr;
};
 
// seul cas qui pose problème ?
list_t *b2 = new Bar;
delete b2;
 
// tout ça est ok ?
Foo f1;
Bar b1;
 
list_t *f2 = new Foo;
delete f2;
 
Foo *f3 = new Foo;
delete f3;
 
Bar *b3 = new Bar;
delete b3;

C'est bien les new qui posent problème dans la classe dérivée en cas d'absence de dtor virtuel ?
Ou même une allocation sur la pile ne sera pas libérée ?

[ternel]

La mémoire interne sera libérée, mais les destructeurs des membres de la classe héritière ne seront pas appelés.

C'est génant pour tout ce qui est détruit: les pointeurs, certes, mais aussi les fermetures de fichier, le commit/rollback d'une transaction sql, une connxion réseau, etc.

[Bousk]

...

Oui, l'absence de virtual fait que le compilo ne va pas créer d'entrée dans la vtable et utiliser le typage statique pour son appel.

[koala01]

Le fait est que, tant que tu connais ton instance de type dérivé comme étant... du type dérivé, il n'y aura aucun problème : c'est le destructeur du type dérivé qui sera appelé, que ce soit de manière implicite (lorsqu'on sort de la portée dans laquelle une variable "classique" est déclarée) ou de manière explicite (avec appel à delete sur un pointeur du type dérivé).

Ainsi, un code proche de

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 MyClass : public std::list</*whatever*/>{
public:
    /* si besoin uniquement */
    ~MyClass(){}
    /* on se fout pas mal du reste */
 
};
int main(){
    if(test){
        MyClass c;
        /* ... */
    } // aucun problème, c est connu comme étant de type MyClass
    MyClass * ptr = new MyClass(/*... */);
    /* ... */
    delete ptr; // aucun problème : ptr est connu comme étant de type MyClass*
   return 0
}

ne posera aucun problème : le type connu par le compilateur correspond bel et bien au type réel des différentes instances, et c'est donc le bon destructeur qui sera appelé.

Les choses vont se compliquer lorsque l'on va commencer à profiter de la substituabilité : comme MyClass hérite de std::list</*whatever*/>, je peux transmettre une instance de MyClass à tout ce qui s'attend à recevoir un std::list</*whatever*/> : sous la forme d'une référence (ou d'un pointeur) à une fonction ou, surtout, je peux parfaitement décider de créer une collection d'objets polymorphes sous une forme proche de

Code :

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

1
2
3
4
5
6
void  foo(){
    std::vector<std::unique_ptr<std::list</*whatever*/> > > tab; // un tableau de pointeurs intelligents sur des éléments 
                                                                                                     // "passant pour être" de type std::list</*whatever*/>
    tab.emplace_back(std::unique_ptr<std::list</*whatever*/>>(new MyClass)); // CRACK
    /* ... */
}

Là, tab ne connait les éléments qu'il contient que comme étant... des pointeurs (intelligents) sur des objets de type std::list</*whatever*/>, ce qui fait que, quand on va retirer un élément de ce tableau, c'est le destructeur de std::list qui sera invoqué.

Mais, comme le destructeur de std::list n'est pas virtuel, le compilateur ne saura pas qu'il doit aller appeler le destructeur de MyClass. Du coup, si le destructeur de MyClass doit faire "quelque chose" (libérer de la mémoire non gérée par un pointeur intelligent, envoyer un signal de déconnection "quelque part", fermer explicitement un fichier qui ne sera fermé que "bien plus tard" autrement, ...) ce ne sera... jamais fait.

Si cela n'arrive qu'une fois ou deux, juste avant que l'application soit de toutes façons quittée, cela ne posera pas vraiment de problème car le système d'exploitation devrait arriver à remettre de l'ordre (en théorie, du moins) dans tout cela. Mais, si cela arrive "à intervalle plus ou moins régulier" et que l'application continue à fonctionner par la suite, cela risque rapidement de provoquer un sacré bordel : le serveur distant risque de maintenir une session active pendant longtemps avant de se rendre compte qu'elle ne l'est plus, la mémoire non libérée finira tôt ou tard par "manquer au système d'exploitation", les fichiers verrouillés ne seront plus accessibles "aux autres applications", j'en passe et sans doute de meilleures.

Et, comme je l'ai fait remarquer plus haut, si on laisse la possibilité à quelqu'un de faire une connerie, on peut avoir la certitude qu'il finira tôt ou tard par la commettre. La question n'étant pas de savoir SI il le fera, mais plutôt QUAND il le fera.

Or, donc... : tant que toutes les instances de MyClass sont connues comme étant des instances de MyClass (et non comme étant des instances de std::list</* whatever */>), il n'y aura aucun problème, nous sommes bien d'accord sur ce point.

Sauf que... tôt ou tard, on voudra sans doute avoir une autre classe (nommons la OtherClass, pour savoir de quoi on parle) qui dérive de std::list</*whatever*/> et que la suite logique sera de vouloir faire cohabiter des instances de type MyClass avec des instances de type OtherClass, et que pour y arriver, nous devrons créer des collections de ... pointeurs (de préférence intelligents) sur std::list</*whatever*/>. Et, bien sur, il y aura forcément une de ces collections (de std::list</*whatever*/>) qui décidera tôt ou tard de détruire les instances vers lequelles pointent les pointeurs qu'elle contient.

Encore une fois, il ne sert à rien de se demander SI ca risque d'arriver, car la loi de finagle est là pour nous dire que cela arrivera forcément. La seule question à se poser est "de combien de temps disposerons nous avant que cela n'arrive". Et la réponse sera toujours à notre désavantage!

La seule conclusion "raisonnable" à faire est donc de se dire que : peut-être n'aurons nous pas tout de suite de problème à faire hériter MyClass de std::list</*whatever*/> mais nous pouvons avoir la certitude que cela ne durera pas. Nous avons donc fortement intérêt à trouver une autre solution"