Discussion :

[kimjoa]

Bonjours !

Voilà je développes un script javascript permettant de faire de l'héritage multiples.

Je me suis beaucoup inspiré du Ruby, qui n'utilise pas vraiment d'héritage multiples, mais des mixins, de plus toutes mes méthodes sont virtuels, donc lors d'appels aux méthodes d'une classes parente, une méthode ne peux être appelée qu'une fois (si j'ai bien compris).

Ne connaissant pas du tout le c++, j'aurais voulue savoir, si 1 méthode est définit plusieurs fois dans les classes parentes , et qu'elle ont les même signatures (prototype), est-ce que ca entraine une erreur de compilation, ou bien est-ce que les méthodes semblables sont appéllé a la suite.

pour faire simple si j'appel une méthode parentes, qui est définit dans plusieurs autres superclass, est-ce que elle sont toutes appellé?

merci

[3DArchi]

Salut,
Dans l'ordre :
1/par défaut les fonctions ne sont pas virtuelles, il faut le mot clé virtual pour qu'elle le soit.
2/Hormis pour le constructeur et le destructeur, il n'y pas d'appel des méthodes parents lorsqu'on appelle la méthode d'un objet même si celle-ci est virtuelle.
3/S'il y a conflit entre deux méthodes parents, une erreur est générée. Le conflit peut être levé en explicitant quelle méthode prendre.
4/Si une classe dérivée redéfinit une méthode non virtuelle, celle-ci 'masque' la méthode parent.
5/Seuls les références et les pointeurs peuvent avoir des types dynamiques et des types statiques différents. Une méthode virtuelle utilise le type dynamique pour l'appel, une méthode non virtuelle, le type statique.

Un peu de code pour illustrer le tout :

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
#include <iostream>
 
class base1
{
   public:
   void f1(){std::cout<<"base1::f1"<<std::endl;}
   void f2(){std::cout<<"base1::f2"<<std::endl;}
   virtual void f3(){std::cout<<"base1::f3"<<std::endl;}
   virtual void f4(){std::cout<<"base1::f4"<<std::endl;}
};
class base2
{
   public:
   void f1(){std::cout<<"base2::f1"<<std::endl;}
   void f2(){std::cout<<"base2::f2"<<std::endl;}
   virtual void f3(){std::cout<<"base2::f3"<<std::endl;}
   virtual void f4(){std::cout<<"base2::f4"<<std::endl;}
};
 
class derive : public base1, public base2
{
   public:
   void f1(){std::cout<<"derive::f1"<<std::endl;}
   virtual void f3(){std::cout<<"derive::f3"<<std::endl;}
};
 
int main()
{
   derive d;
   std::cout<<"*****"<<std::endl<<"derive : "<<std::endl;
   d.f1();
//   d.f2();  request for member 'f2' is ambiguous
   d.base1::f2(); // explicite
   d.base2::f2();
   d.f3();
//   d.f4(); request for member 'f4' is ambiguous
   d.base1::f4();
   d.base2::f4();
 
   base1 &r_b1=d; // référence
   std::cout<<"*****"<<std::endl<<"base1 : "<<std::endl;
   r_b1.f1();
   r_b1.f2();
   r_b1.f3();
   r_b1.f4();
 
   base2 *p_b2=&d; // pointeur
   std::cout<<"*****"<<std::endl<<"base2 : "<<std::endl;
   p_b2->f1();
   p_b2->f2();
   p_b2->f3();
   p_b2->f4();
 
   base1 b_perdu = d;
   std::cout<<"*****"<<std::endl<<"b_perdu : "<<std::endl;
   b_perdu.f1();
   b_perdu.f2();
   b_perdu.f3();
   b_perdu.f4();
}

Résultat :

*****
derive :
derive::f1
base1::f2
base2::f2
derive::f3
base1::f4
base2::f4
*****
base1 :
base1::f1
base1::f2
derive::f3
base1::f4
*****
base2 :
base2::f1
base2::f2
derive::f3
base2::f4
*****
b_perdu :
base1::f1
base1::f2
base1::f3
base1::f4

[kimjoa]

merci de votre réponse

1/par défaut les fonctions ne sont pas virtuelles, il faut le mot clé virtual pour qu'elle le soit.
2/Hormis pour le constructeur et le destructeur, il n'y pas d'appel des méthodes parents lorsqu'on appelle la méthode d'un objet même si celle-ci est virtuelle.
3/S'il y a conflit entre deux méthodes parents, une erreur est générée. Le conflit peut être levé en explicitant quelle méthode prendre.
4/Si une classe dérivée redéfinit une méthode non virtuelle, celle-ci 'masque' la méthode parent.
5/Seuls les références et les pointeurs peuvent avoir des types dynamiques et des types statiques différents. Une méthode virtuelle utilise le type dynamique pour l'appel, une méthode non virtuelle, le type statique.

1/mes méthodes seront toujours virtuels, pour moi ca semble plus logique, (ex : j'hérite de papa et maman, papa et maman parle la même langue, alors j'hérite que d'une langue )
2/ok les constructeurs sont appelé automatiquement, mais pK? l'inverse serait sans doute plus souple non?
3/Ok, c'est ce que je voulais savoir , finalement les mixins (type ruby)me semble plus approprié, et enlève toutes source d'erreurs lors d'héritage ou l'on ne connais pas bien les classe de base
4/ok , la méthode non virtuelle est prioritaire, mais il y a une explication derrière cette règle?
5/Hmm , pour faire simple le type d'une méthode non virtuel est initialisé a la compilation?

Si vous répondez pas , c'est pas grave, ...

a++

[3DArchi]

1/mes méthodes seront toujours virtuels, pour moi ca semble plus logique, (ex : j'hérite de papa et maman, papa et maman parle la même langue, alors j'hérite que d'une langue )

Ca n'est ni forcément intéressant, ni forcément souhaitable. Une méthode définie par une classe peut ne pas avoir à être spécialisée par une classe dérivée. Et notamment sur le pattern NVI (cf F.A.Q. C++ : mes méthodes virtuelles doivent-elles être publiques, protégées ou privées ?). Ou encore pourquoi rendre virtuelle un méthode de cuisine interne de la classe de base qui n'a pas de sens même pour une classe dérivée ?

2/ok les constructeurs sont appelé automatiquement, mais pK? l'inverse serait sans doute plus souple non?

Pour le constructeur (et symétriquement pour le destructeur), il est indispensable que les appels des classes de bases soient faits (pour le constructeur de haut en bas, pour le destructeur de bas en haut de l'arbre d'héritage, cf FA.Q. C++ sur comment sont construits les objets) de façon à assurer qu'un objet est bien totalement construit (resp. détruit).
Pour les autres méthodes, je ne vois aucune raison pour ce qu'il y ait un appel implicite vers la classe de base. J'ai parfois besoin de spécialiser complètement le comportement d'une fonction et l'appel à la classe de base serait une erreur. Ensuite, il y a des cas où je dois appeler la classe de base en début de la spécialisation et d'autres à la fin. Comment décider où faire cet appel implicite ? Pour un constructeur (resp. destructeur), la logique est qu'il faut d'abord avoir construit les ancêtres avant de construire le descendant (modulo la subtilité de l'héritage virtuel), mais pour les autres méthodes il n'y a pas de comportement plus évident qu'un autre.

4/ok , la méthode non virtuelle est prioritaire, mais il y a une explication derrière cette règle?
5/Hmm , pour faire simple le type d'une méthode non virtuel est initialisé a la compilation?

En fait, je me suis peut être mal expliqué au début.
Une variable en C++ a deux types : le type dynamique et le type statique (cf F.A.Q. Que sont le typage statique et le typage dynamique ? Question subsidiaire : qu'est-ce que l'inférence de type ?). Le type statique est celui déclaré à la compilation. Le type dynamique est le type effectif de la variable à l'exécution.

Code :

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

1
2
3
4
5
6
7
8
9
 
class base{};
classe derivee : public base{};
 
derivee d; // type statique = derivee, type dynamique = derivee
base b; // type statique = base, type dynamique = base
base &reference=d;// type statique = base, type dynamique = derivee
base *pointeur=&d;// type statique = base, type dynamique = derivee
base attention = d;// type statique = base, type dynamique = base car ce n'est ni une référence ni un pointeur et ce malgré qu'on le construise à partir d'un objet derivee

Lorsqu'on appelle une fonction f non virtuelle sur un objet o, alors ce qui est pris en compte pour savoir quelle version de f appelée est le type statique. Le lien est fait à la compilation.
Lorsqu'on appelle une fonction f virtuelle sur un objet o, alors ce qui est pris en compte pour savoir quelle version de f appelée est le type dynamique. Le lien est fait à l'exécution.... sous réserves ci-dessous :
Seuls les pointeurs et les références ont un type dynamique et un type statique éventuellement distincts.
Pour un objet par valeur - ayant donc le même type dynamique et le même type statique - la fonction f appelée est toujours déterminée à la compilation que f soit virtuelle ou non.

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
 
class base{
  void f_1(){}
  virtual void f_2();
  void f_3();
};
classe derivee : public base
{
   virtual void f_2();
   void f_3();
};
 
derivee d; // type statique = derivee, type dynamique = derivee
d.f_1(); // -> résolue à la compilation : base::f_1
d.f_2(); // -> résolue à la compilation : derivee::f_2 car d n'est ni un pointeur ni une référence
d.f_3(); // -> résolue à la compilation : derivee::f_3
 
base b; // type statique = base, type dynamique = base
b.f_1(); // -> résolue à la compilation : base::f_1
b.f_2(); // -> résolue à la compilation : base::f_2 car b n'est ni un pointeur ni une référence
b.f_3(); // -> résolue à la compilation : base::f_3
 
base &reference=d;// type statique = base, type dynamique = derivee
reference.f_1(); // -> résolue à la compilation : base::f_1
reference.f_2(); // -> résolue à l'exécution avec le type dynamique : derivee::f_2
reference.f_3(); // -> résolue à la compilation : base::f_3
 
derivee &reference_derivee=d;// type statique = derivee, type dynamique = derivee
reference_derivee.f_1(); // -> résolue à la compilation : base::f_1
reference_derivee.f_2(); // -> résolue à l'exécution avec le type dynamique : derivee::f_2
reference_derivee.f_3(); // -> résolue à la compilation car f_3 n'est pas virtuelle: derivee::f_3 car derivee::f_3 masque base::f_3

[kimjoa]

merci pour ces expilcations 3DArchi !!

Je dois avouez que je suis un peu dépassé, n'ayant jamais programmer un c++, tout ses concepts me sont un peu flou...

Ca n'est ni forcément intéressant, ni forcément souhaitable. Une méthode définie par une classe peut ne pas avoir à être spécialisée par une classe dérivée. Et notamment sur le pattern NVI (cf F.A.Q. C++ : mes méthodes virtuelles doivent-elles être publiques, protégées ou privées ?). Ou encore pourquoi rendre virtuelle un méthode de cuisine interne de la classe de base qui n'a pas de sens même pour une classe dérivée ?

Je crois avoir confondue le concept de class virtuel et de méthode virtuel.
On peux dire que en javascript toute les méthodes sont virtuels. Il existe en javascript des fonctions spéciale pour permettre d'appeler une fonction dans un contexte précis, des-lors le lien qui lie le contexte de cette fonction est cassé, ou plutôt est remplacé par celui définit.

(je voulais que lors de l'appel à une méthode d'une super classe, cette méthode ne soit plus rappeler par les autres appels à des méthodes des super classe, un peu comme les appels des constructeurs des classes virtuels,
qui doivent être appelé qu'une fois)

Pour un constructeur (resp. destructeur), la logique est qu'il faut d'abord avoir construit les ancêtres avant de construire le descendant

ca semble logique , en effet

Pour les autres méthodes, je ne vois aucune raison pour ce qu'il y ait un appel implicite vers la classe de base. J'ai parfois besoin de spécialiser complètement le comportement d'une fonction et l'appel à la classe de base serait une erreur. Ensuite, il y a des cas où je dois appeler la classe de base en début de la spécialisation et d'autres à la fin. Comment décider où faire cet appel implicite ?

Oui, c'est vrai, et pourtant , là été l'objectif de mon script, faire des appels au super méthode un peu comme en java, mais en prenant en compte l'héritage multiple (avec des mixins comme en ruby).
Du coup je suis un peu perdu, des langages réputé utilise cette technique d'appel, mais après ce que vous avez dit, qui parait tout à fait juste, c'est langages ce trouvrait-il dans l'erreur?
De plus comme je vous l'ai dit , en javascript on peu appeler une méthode pour un contextz précis, du coup, ca ressemble beaucoup au c++.

Voilà je pense que je vais suivre le modèle c++, qui sera beaucoup facile à programmer, et qui semble tout de même plus logique.
Je vais rendre par défaut toute mes classes virtuels, étant donné que l'on peux appeler un constructeur comme une méthode.

merci pour toute ses explications, je posterais mon script sur le forum javascript -> contribuez, je vous préviendrais sur ce post

bye !

[koala01]

Salut,

Oui, c'est vrai, et pourtant , là été l'objectif de mon script, faire des appels au super méthode un peu comme en java, mais en prenant en compte l'héritage multiple (avec des mixins comme en ruby).
Du coup je suis un peu perdu, des langages réputé utilise cette technique d'appel, mais après ce que vous avez dit, qui parait tout à fait juste, c'est langages ce trouvrait-il dans l'erreur?

La réponse à cette question oscille sans doute entre "oui, mais non" et "non, quoi que..."

Il faut en effet comprendre que tous les langages ont la même finalité: faire comprendre à quelque chose d'aussi bête qu'un ordinateur ce que l'on attend de lui.

Seulement, chaque langage a sa propre philosophie, qui fait entre autres, que certains préfèrent un langage et honnissent un autre alors que d'autres préfèrent l'autre langage et honnissent le premier.

Cette philosophie transparait déjà, tout simplement, dans le fait de faire travailler une machine virtuelle entre le code que l'on crée et l'ordinateur auquel on s'adresse, ou entre le fait de décider que toute classe descendra implicitement d'une classe de base ("object" ) ou non.

Et une grande partie de la philosophie du langage vient de l'estime dans laquelle on tient le développeur:

En caricaturant presque un peu, nous pourrions dire que java n'a qu'une piètre opinion du développeur et le considère comme incapable de comprendre le problème de l'héritage multiple lorsqu'il y a une base commune, ce qui implique certaines restrictions dans ce que le langage accepte.

En ne caricaturant qu'à peine moins, nous pourrions dire que C++ a une haute estime du développeur (peut être un peu trop haute, d'ailleurs, du moins en ce qui concerne certains) et se base sur le fait qu'il (le développeur) sait ce qu'il fait pour lui laisser une liberté accrue... allant jusqu'à celle de faire de fantastiques boulettes.

Cette philosophie fait que certains langages mettent plus ou moins d'empressement à respecter ce que d'autres élèvent au rang de principe ou de loi (je pense, entre autres, au principe de substitution de liskov ou à la loi demeter)

Au final, lorsque l'on a l'esprit tourné vers le C++, on peut, très certainement estimer que les autres langages (java en tête) "fait fausse route", mais pour quelqu'un ayant l'esprit java, la sensation est très vraisemblablement inversée (ce serait plutôt C++ qui est dans l'erreur), le tout dépendant au final énormément du ressenti personnel de chacun

Mais, arrêtons nous là, pour éviter de relancer le bon vieux débat C++ Vs java qui a, par ailleurs, sa propre discussion

De plus comme je vous l'ai dit , en javascript on peu appeler une méthode pour un contextz précis, du coup, ca ressemble beaucoup au c++.

Voilà je pense que je vais suivre le modèle c++, qui sera beaucoup facile à programmer, et qui semble tout de même plus logique.
Je vais rendre par défaut toute mes classes virtuels, étant donné que l'on peux appeler un constructeur comme une méthode.

Attention, il y a une différence entre une classe virtuelle (abstraite, en réalité) et une fonction virtuelle...

La première est une classe qui ne pourra pas être instanciée par elle-même et qui ne pourra l'être qu'au travers des classes dérivées qui en redéfinissent toutes les fonctions virtuelles pures.

Une fonction virutelle est une fonction au sujet de laquelle on prévient le compilateur que le comportement est susceptible d'être modifié en fonction du type dynamique de la variable utilisée.

Il faut savoir que C++ a l'habitude de ne pas faire payer le cout de quelque chose si ce n'est pas absolument indispensable.

Or, le fait d'appeler une fonction virtuelle a un cout (en terme d'indirection) supplémentaire par rapport au cout de l'appel d'une fonction qui ne l'est pas.

Si tu rend toutes tes fonctions virtuelles, tu te trouvera dans une situation dans laquelle:

• Tu laisse penser qu'il peut être opportun de redéfinir certaines fonctions qui n'ont pas lieu de l'être (parce que le comportement défini pour la classe de base correspond à celui que l'on attend des classes dérivées)
• A force d'ajout d'indirections supplémentaires, tu finira tôt ou tard par plomber littéralement les performances de ton application

En C++, la règle concernant la virtualité des fonctions est inversée par rapport à la règle suivie par java sur le sujet:

En C++, une fonction n'est pas virtuelle, sauf si l'auteur du code le précise explicitement, alors qu'en java, une fonction est, par défaut, virtuelle, sauf si l'auteur du code précise explicitement qu'elle ne l'est pas (par le mot clé final, il me semble).

Si tu décide de coder en C++ en inversant la règle générale, *peut-être* aurais tu meilleur temps d'envisager de te tourner vers java, histoire de ne pas être quasi en permanence du coté de l'exception

[kimjoa]

dsl de vous répondre que si tardivement, je n'avais pas vue votre message !

Attention, il y a une différence entre une classe virtuelle (abstraite, en réalité) et une fonction virtuelle...

La première est une classe qui ne pourra pas être instanciée par elle-même et qui ne pourra l'être qu'au travers des classes dérivées qui en redéfinissent toutes les fonctions virtuelles pures.

Une fonction virutelle est une fonction au sujet de laquelle on prévient le compilateur que le comportement est susceptible d'être modifié en fonction du type dynamique de la variable utilisée.

En faite j'ai encore confondue deux concept , l'héritage virtuelle , et une classe virtuelle toutes mes classes seront hérité virtuellement pour éviter les problème d'héritage en diamant.

Il faut savoir que C++ a l'habitude de ne pas faire payer le cout de quelque chose si ce n'est pas absolument indispensable.

Or, le fait d'appeler une fonction virtuelle a un cout (en terme d'indirection) supplémentaire par rapport au cout de l'appel d'une fonction qui ne l'est pas.

Si tu rend toutes tes fonctions virtuelles, tu te trouvera dans une situation dans laquelle:

* Tu laisse penser qu'il peut être opportun de redéfinir certaines fonctions qui n'ont pas lieu de l'être (parce que le comportement défini pour la classe de base correspond à celui que l'on attend des classes dérivées)
* A force d'ajout d'indirections supplémentaires, tu finira tôt ou tard par plomber littéralement les performances de ton application

Le but de mon projet été de rendre compatible l'héritage multiple en javascript. Hors ce langage n'est pas vraiment orienté classe, ce qui permet pas l'encapsulation des données. Les appels au méthodes parentes, sont faite par une autre fonction qui contextualise l'appel, à l'instance. Alors que dans les langages a classe, l'appel des méthodes parentes ont aussi un contexte de classe , celle dans laquel la fonction est définit, pour que lors d'autre appel depuis cette fonction l'interpréteur ou compilateur cherche d'abord dans la classe de l'appel de la fonction et non pas de celle du type de l'objet .
Cette particularité peux être levé en c++ grâce au mot clé virtual, permettant le polymorphisme si j'ai bien compris.
En javascript toutes les méthode sont virtuelle, et on peux pas faire autrement

Si tu décide de coder en C++ en inversant la règle générale, *peut-être* aurais tu meilleur temps d'envisager de te tourner vers java, histoire de ne pas être quasi en permanence du coté de l'exception

Tout les langages mériterait qu'on y passe un peux de temps , pour le moment j'ai assez a faire avec le js, php, et as ... mais plein d'autre me font de l'œil , notement le Python , java, c++, ruby ....

Merci pour votre commentaire, je vais dans la journée inclure mon projet a www.developpez.net

[kimjoa]

j'ai finit mon script, vous pouvais l'essayé ici http://www.developpez.net/forums/d86...e/#post4908040

a++

[3DArchi]

Salut,
Entre temps, ta question et d'autres voisines m'ont amenés à approfondir la notion de fonctions virtuelles en C++. Si cela t'intéresse : les fonctions virtuelles en C++ (et le fil de discussion associé)