quelques questions sur le c++ et l'héritage

Bonjour,

j'apprend le c++ et j'ai 3 questions :

1) Concernant le langage même je n'est pas compris l'héritage je crois : j'ai lu qu'une instance B de la classe CB héritant de la classe CA ne pouvait pas recevoir une instance de classe CA mais que A de classe CA pouvait recevoir B...Je pensais que c'étatit le contraire.

2) L'intérêt de déclarer des variables private et non protected puisque protected est plus large (même si non indispensable).

3) Ma deuxième question est loin de ça : j'ai pas mal codé en C avec GTK+ et j'ai vu qu'il existait gtkmm pour le c++, je recherche de bons tutoriaux.

Là où mes deux questions (1 et 3) sont liés, c'est qu'en C/GTK+ je déclaré un Widget et je l'utilisé pour tous les widget (label, entry, window ...). Alors que d'après ce que j'ai compris ce n'est pas logique d'un point de vue classe...

1) Pas claire comme ca :aie:
Montre du code, ca sera plus simple pour t'expliquer.

2) Une variable protected est accessible aux classes dérivées mais reste néanmoins inaccessible depuis l'extérieur de la classe.

3) Bien que Gtk++ soit un wrapper de GTK pour le C++, je ne peux que conseiller Qt à la place de celle ci.
Mais si tu souhaite rester avec GTK, j'ai trouvé ceci :
http://www.xgarreau.org/aide/devel/langtk/cpp_gtkmm.php

Salut,

je voudrais te donner un conseil d'ordre général, pose une seul question par post, sinon tu recevra moins de réponses (moi au début j'avais vraiment pas envie de tout lire et encore moins de te répondre)

1) il faut se représenter l'héritage avec des images concrètes : un Animal (classe mère) peut etre un Chat ou autre chose, tandis qu'un Chat ne peut pas etre défini par juste "Animal".. Un Chat c'est une instance spécialisée d'Animal, et donc tu ne peut pas mettre une instance d'Animal dans une variable de Type, car il manquera des infos à cette variable pour etre complètement un chat.

2) les variables private ne sont pas accessible aux classes filles, parfois c'est ce qu'on veut

3) pareil que Davidbrcz. si tu code en C, utilise Gtk, si tu travaille en C++, plutot Qt. je ne me souviens plus de tout les problèmes que j'avais eu avec gtkmm, mais j'en avais bavé pour l'installation sous windows par exemple.

3) ok, je voulais utilisé GTK-- car sous gnome qt est moche mais bon, ce n'est pas le plus important.

2) ok, moi je voyais les choses à l'envers alors.

1) Un Animal ne peut pas être un Chat ça me semble logique mais c'est ce que j'ai lu. J'ai trouvé que seul les attributs en commun sont hérités ainsi que l'adresse ce qui me rassure un peu.

FULL HS : Je sais pas si c'est moi ou quoi mais je ne n'ai toujours rien compris à tes propos sur l'héritage et pourtant je l'ai bien relu 5 ou 6 fois ta phrase. Mais je n'y comprend vraiment rien :aie: .

je vais tenter un bout de code (plus pour l'idée qu'autre chose) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class Pere { .... }   class Fils { Fils(int n); } int main(void) { Pere p; F f(1); p=f; return 0; }

---

Ce code est correct même si f a plus d'arguments que p, p=f revient à affecter l'adresse de f à p puis d'égaliser les attributs communs...d'après ce que j'ai compris, j'aimerais qu'on me le confirme.

Tu as ici un phénomène de slicing (perte d'information suite à convertion).

Généralement, on ne manipule jamais par valeur les objets issues de hiérarchies où l'héritage sert à supporter une substituabilité.
Une bonne pratique consiste à interdire affectations et copies dans les objets polymorphes, vu que souvent cela n'a aucun sens.

En conclusion, utilises pointeurs et références.

Gtkmm c'est très bien, je comprends pas pourquoi on te dit d'utiliser Qt.
C'est du beau C++, propre et standard, contrairement à Qt. Et ça se limite au GUI, contrairement à Qt qui duplique tout ce que font mieux d'autres bibliothèques spécialisées ou la bibliothèque standard.

Citation:

---

je ne me souviens plus de tout les problèmes que j'avais eu avec gtkmm, mais j'en avais bavé pour l'installation sous windows par exemple.

---

Les binaires pour windows de PyGTK et GTKmm ne sont pas sur le site officiel il me semble, oui. Mais ça se trouve facilement.

ok, un dernier post pour demander un petit détail sur gtkmm :

en gtk+ j'utilise des gtkwidget pour à peu prés tout, mais les code gtkmm spécialise tout de suite les widgets (gtkwindow par exemple), pourquoi ?

Histoire de simplifier tout ça:

• Un type dérivé du type C est un sous-type Sc de C.
• Une sous-type Sc étends C d'une manière ou d'une autre - soit en changeant son comportement (utilisation du polymorphisme d'héritage), soit en ajoutant des propriétés (variables) ou des comportements (méthodes).
• Une instance de Sc possède tous les attributs d'une instance de C.
• Donc il est possible de considérer qu'une instance de Sc est une instance particulière de C.
• (il en découle d'ailleurs que du point de vue de l'extérieur, une instance de Sc doit se comporter comme une instance de C; c'est le principe de substitution de Liskov).
• Une instance de C possède moins d'attributs qu'une instance de Sc.
• Donc une instance de C ne peut pas être une instance particulière de Sc.

Conclusion: passer de Sc à C est automatique, tandis que l'inverse est interdit par défaut.

Ensuite, le problème de protected par rapport à private:

• principe fondamental: en programmation objet, on programme vers une interface, et non pas vers une implémentation.
• Une variable est du domaine de l'implémentation, et non pas de l'interface.
• Si une variable est accessible depuis l'exterieur, la ligne entre l'interface et l'implémentation est brisée.
• Une classe Sc est externe à une classe C.
• Les variables protected de C sont visibles dans les classes Sc.
• En utilisant une variable protected de C dans une classe Sc, on utilise l'implémentation de C et non pas son interface.
• Donc on passe outre le principe fondamental précédemment exprimé.

Conclusion: il vaut mieux éviter d'utiliser des variables et méthode protected lorsqu'on définit une classe.

Bien évidemment, private ne pose pas ce problème.

Citation:

---

2) les variables private ne sont pas accessible aux classes filles, parfois c'est ce qu'on veut

---

Promis, non. Ce qu'on souhaite, c'est réutiliser du code. Hors, on hérite pas d'une classe pour réutiliser du code - il est préférable de composer les objets si tel est notre but.

ok, merci.