Folco (./928) :
Ca signifie donc que la classe mère comporte un constructeur, alors qu'on pourrait s'en passer si la classe dérivée construisait les objets protected. Ok.

Ça c'est pas vraiment (pas du tout) une manière propre de faire.

Sinon, g++ refuse que mon destructeur de classe mère ne soit pas virtuel, pourquoi ? Quelle est la conséquence que ce destructeur soit virtuel ?

Tiens je savais pas que le compilo t'interdisait carrément les destructeurs non virtuels ^^
Mais en gros c'est simple. Normalement, le C++ est compilable sans RTTI (l'équivalent très modeste de la réflexion en C# ou Java).(); // B dérive de ADonc si tu déclares A* truc = new BAlors, le compilateur sait juste que "*truc" est de type A. Si ton destructeur n'est pas virtuel, il va apeller le destructeur de A, puisque il sait seulement que *truc est de type A.
En revanche, avec un destructeur virtuel, il va apeller le destructeur attitré à "truc", à savoir soit le destructeur de A, soit celui de B si B a redéfini le destructeur de A… Tes ressources seront ainsi bien libérées comme il faut.

Il va en fait être redéfini par la classe dérivée, mais les deux destructeurs seront appelés simultanément lors de la destruction de l'"objet dérivé" ? (CROSS !!! Je tombe sur ça GC, mais pourquoi ???)

Ils ne sont pas appelés simultanément. Les éléments de la classe enfant dépendent (potentiellement) des éléments de la classe parent.
C'est comme quand tu t'habilles et te déshabilles. Tu mets d'abord le slip, puis le pantalon, et puis tu retires le pantalon avant de retirer le slip (car le pantalon est par dessus le slip). Tu ne peux pas retirer le slip avant le patanlon (enfin, tu peux en te tordant bizarrement, ok…), à moins que tu n'aies également mis le slip après avoir mis le pantalon

Pour continuer le cross, oui, j'ai relu cet après-midi le chapitre sur l'héritage multiple, ça suppose visiblement de bien poser ses mécanismes d'héritages et de virtualisation pour ne pas se faire baiser...

Bah, le C++ est un peu trop permissif sur ce point malheureusement, mais si tu te limites à de l'héritage multiple propre comme en C#, Java & compagnie, y'a pas besoin d'énormément de contorsions neurales ^^

Et enfin, je suis dans le cas d'une classe mère jamais instanciée en stand-alone (aucun intérêt, l'objet n'est pas fait pour ça et ne représenterait rien). C'est d'ailleurs pour ça que toutes ses méthodes sont virtuelles, sans implémentation.

Ouais, mais dans beaucoup de cas tu auras également besoin d'une classe abstraite, proposant une partie de l'implémentation, et demandant aux enfants d'implémenter le reste. Une classe purement abstraite (une interface), par contre, ne doit pas déclarer quoi que ce soit d'autre que des méthodes virtuelles "pures" (au sens C++).
D'ailleurs j'espère que tu as bien pensé à déclarer tes méthodes comme telles ^^
(PS: virtual void machinChose() = 0