Je débute en c++, uniquement avec les ressources du net, et
je cherche un moyen de faire lire par mon programme le contenu
d'un répertoire (comme la très classique commande dir).
J'ai cherché sans succès avec google et suis encore occuper
à fouiller les archives de cppfrance.com.
Regardes du côté de l'héritage virtuel, des vtordisp, et autres joyeusetés! Ca complique aussi énormément la logique des pointeurs de méthodes : Quelle est la taille d'un pointeur de méthode (sur un compilateur donné), selon les modèle d'héritage de la classe?
Jamais réfléchit en profondeur au problème. J'ai l'impression que deux pointeurs suffisent mais je me trompe peut-être.
http://www.codeproject.com/cpp/FastDelegate.asp Regardes le paragraphe "Implementation of member functions pointers".
Est-il légal de caster un pointeur vers une méthode de classe dérivée en pointeur vers une méthode de la classe de base?
5.2.9/8 : oui, sous certaines conditions.
Exact, et qu'est ce qu'on peut faire ensuite du pointeur casté? Rien!
Si j'ai bonne mémoire -- je suis rentré mais j'ai rien relu -- les conditions en question sont celles pour lesquelles le pointeur résultant peut être utilisé avec une sémantique définie.
Par ailleurs, le CLR définit un modèle objet et un mécanisme d'introspection de ce modèle, et ce modèle ne supporte que l'héritage simple d'implémentation (c'est très proche du Java).
L'introspection voit une structure hierarchique plus complexe. C'est tout.
"Bien sûr", mais ca demanderait de mettre à jour tous les langages .NET (détail!),
Les langages n'ayant pas d'héritage multiple voient une hiérarchie avec de l'héritage simple. Rien à mettre à jour où je ne te comprends pas. Éventuellement il faudrait définir la manière précise d'organiser cet héritage pour que les langages (tiens si j'ai bonne mémoire il y a un Eiffel pour .NET) ayant un héritage multiple le fasse de la même façon.
et de toute façon, je ne pense pas que ça corresponde à la "philosophie" .NET, qui est d'interdire l'héritage multiple d'implémentation car elle est souvent mal utilisée (conceptions objet foireuses qui utilisent l'héritage multiple à la place de l'aggrégation).
As-tu un pointeur vers un document décrivant la "philosophie" .NET, expliquant les choix faits et leurs raisons?
As-tu une définition d'un "bon usage" de l'héritage multiple? Y at'il consensus dessus?
As-tu des stats sur l'utilisation effective de l'héritage multiple analysée en fonction de ce bon usage?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Regardes du côté de l'héritage virtuel, des vtordisp, et
autres joyeusetés! Ca complique aussi énormément la
logique des pointeurs de méthodes : Quelle est la taille
d'un pointeur de méthode (sur un compilateur donné), selon
les modèle d'héritage de la classe?
Jamais réfléchit en profondeur au problème. J'ai
l'impression que deux pointeurs suffisent mais je me trompe
peut-être.
http://www.codeproject.com/cpp/FastDelegate.asp
Regardes le paragraphe "Implementation of member functions pointers".
Est-il légal de caster un pointeur vers une méthode de
classe dérivée en pointeur vers une méthode de la classe
de base?
5.2.9/8 : oui, sous certaines conditions.
Exact, et qu'est ce qu'on peut faire ensuite du pointeur
casté? Rien!
Si j'ai bonne mémoire -- je suis rentré mais j'ai rien
relu -- les conditions en question sont celles pour
lesquelles le pointeur résultant peut être utilisé avec une
sémantique définie.
Par ailleurs, le CLR définit un modèle objet et un
mécanisme d'introspection de ce modèle, et ce modèle ne
supporte que l'héritage simple d'implémentation (c'est
très proche du Java).
L'introspection voit une structure hierarchique plus
complexe. C'est tout.
"Bien sûr", mais ca demanderait de mettre à jour tous les
langages .NET (détail!),
Les langages n'ayant pas d'héritage multiple voient une
hiérarchie avec de l'héritage simple. Rien à mettre à jour
où je ne te comprends pas. Éventuellement il faudrait
définir la manière précise d'organiser cet héritage pour que
les langages (tiens si j'ai bonne mémoire il y a un Eiffel
pour .NET) ayant un héritage multiple le fasse de la même
façon.
et de toute façon, je ne pense pas que ça corresponde à la
"philosophie" .NET, qui est d'interdire l'héritage
multiple d'implémentation car elle est souvent mal
utilisée (conceptions objet foireuses qui utilisent
l'héritage multiple à la place de l'aggrégation).
As-tu un pointeur vers un document décrivant la
"philosophie" .NET, expliquant les choix faits et leurs
raisons?
As-tu une définition d'un "bon usage" de l'héritage
multiple? Y at'il consensus dessus?
As-tu des stats sur l'utilisation effective de l'héritage
multiple analysée en fonction de ce bon usage?
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Regardes du côté de l'héritage virtuel, des vtordisp, et autres joyeusetés! Ca complique aussi énormément la logique des pointeurs de méthodes : Quelle est la taille d'un pointeur de méthode (sur un compilateur donné), selon les modèle d'héritage de la classe?
Jamais réfléchit en profondeur au problème. J'ai l'impression que deux pointeurs suffisent mais je me trompe peut-être.
http://www.codeproject.com/cpp/FastDelegate.asp Regardes le paragraphe "Implementation of member functions pointers".
Est-il légal de caster un pointeur vers une méthode de classe dérivée en pointeur vers une méthode de la classe de base?
5.2.9/8 : oui, sous certaines conditions.
Exact, et qu'est ce qu'on peut faire ensuite du pointeur casté? Rien!
Si j'ai bonne mémoire -- je suis rentré mais j'ai rien relu -- les conditions en question sont celles pour lesquelles le pointeur résultant peut être utilisé avec une sémantique définie.
Par ailleurs, le CLR définit un modèle objet et un mécanisme d'introspection de ce modèle, et ce modèle ne supporte que l'héritage simple d'implémentation (c'est très proche du Java).
L'introspection voit une structure hierarchique plus complexe. C'est tout.
"Bien sûr", mais ca demanderait de mettre à jour tous les langages .NET (détail!),
Les langages n'ayant pas d'héritage multiple voient une hiérarchie avec de l'héritage simple. Rien à mettre à jour où je ne te comprends pas. Éventuellement il faudrait définir la manière précise d'organiser cet héritage pour que les langages (tiens si j'ai bonne mémoire il y a un Eiffel pour .NET) ayant un héritage multiple le fasse de la même façon.
et de toute façon, je ne pense pas que ça corresponde à la "philosophie" .NET, qui est d'interdire l'héritage multiple d'implémentation car elle est souvent mal utilisée (conceptions objet foireuses qui utilisent l'héritage multiple à la place de l'aggrégation).
As-tu un pointeur vers un document décrivant la "philosophie" .NET, expliquant les choix faits et leurs raisons?
As-tu une définition d'un "bon usage" de l'héritage multiple? Y at'il consensus dessus?
As-tu des stats sur l'utilisation effective de l'héritage multiple analysée en fonction de ce bon usage?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
"Arnaud Debaene" writes:
Jean-Marc Bourguet wrote:
Regardes du côté de l'héritage virtuel, des vtordisp, et autres joyeusetés! Ca complique aussi énormément la logique des pointeurs de méthodes : Quelle est la taille d'un pointeur de méthode (sur un compilateur donné), selon les modèle d'héritage de la classe?
Jamais réfléchit en profondeur au problème. J'ai l'impression que deux pointeurs suffisent mais je me trompe peut-être.
http://www.codeproject.com/cpp/FastDelegate.asp Regardes le paragraphe "Implementation of member functions pointers".
À voir les tailles données, 2 pointeurs a bien l'air d'être ce qui est utilisé par certains compilateurs. Je devrais peut-être lire tout ça pour voir ce qui pousse d'autres à utiliser plus de place.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Regardes du côté de l'héritage virtuel, des vtordisp, et
autres joyeusetés! Ca complique aussi énormément la
logique des pointeurs de méthodes : Quelle est la taille
d'un pointeur de méthode (sur un compilateur donné), selon
les modèle d'héritage de la classe?
Jamais réfléchit en profondeur au problème. J'ai
l'impression que deux pointeurs suffisent mais je me trompe
peut-être.
http://www.codeproject.com/cpp/FastDelegate.asp
Regardes le paragraphe "Implementation of member functions pointers".
À voir les tailles données, 2 pointeurs a bien l'air d'être
ce qui est utilisé par certains compilateurs. Je devrais
peut-être lire tout ça pour voir ce qui pousse d'autres à
utiliser plus de place.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Regardes du côté de l'héritage virtuel, des vtordisp, et autres joyeusetés! Ca complique aussi énormément la logique des pointeurs de méthodes : Quelle est la taille d'un pointeur de méthode (sur un compilateur donné), selon les modèle d'héritage de la classe?
Jamais réfléchit en profondeur au problème. J'ai l'impression que deux pointeurs suffisent mais je me trompe peut-être.
http://www.codeproject.com/cpp/FastDelegate.asp Regardes le paragraphe "Implementation of member functions pointers".
À voir les tailles données, 2 pointeurs a bien l'air d'être ce qui est utilisé par certains compilateurs. Je devrais peut-être lire tout ça pour voir ce qui pousse d'autres à utiliser plus de place.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
"Arnaud Debaene" writes:
Jean-Marc Bourguet wrote: [...]
Regardes du côté de l'héritage virtuel, des vtordisp, et autres joyeusetés! Ca complique aussi énormément la logique des pointeurs de méthodes : Quelle est la taille d'un pointeur de méthode (sur un compilateur donné), selon les modèle d'héritage de la classe?
Jamais réfléchit en profondeur au problème. J'ai l'impression que deux pointeurs suffisent mais je me trompe peut-être.
http://www.codeproject.com/cpp/FastDelegate.asp Regardes le paragraphe "Implementation of member functions pointers".
[...] l'héritage multiple d'interfaces est autorisé [...]
À partir du moment où l'héritage multiple d'interfaces est autorisé, je me demande quelles complications additionnelles il y aurait dans les pointeurs vers membres avec un héritage multiple plus général.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Regardes du côté de l'héritage virtuel, des vtordisp, et
autres joyeusetés! Ca complique aussi énormément la
logique des pointeurs de méthodes : Quelle est la taille
d'un pointeur de méthode (sur un compilateur donné), selon
les modèle d'héritage de la classe?
Jamais réfléchit en profondeur au problème. J'ai
l'impression que deux pointeurs suffisent mais je me trompe
peut-être.
http://www.codeproject.com/cpp/FastDelegate.asp
Regardes le paragraphe "Implementation of member functions pointers".
[...]
l'héritage multiple d'interfaces est autorisé
[...]
À partir du moment où l'héritage multiple d'interfaces est autorisé,
je me demande quelles complications additionnelles il y aurait dans
les pointeurs vers membres avec un héritage multiple plus général.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Regardes du côté de l'héritage virtuel, des vtordisp, et autres joyeusetés! Ca complique aussi énormément la logique des pointeurs de méthodes : Quelle est la taille d'un pointeur de méthode (sur un compilateur donné), selon les modèle d'héritage de la classe?
Jamais réfléchit en profondeur au problème. J'ai l'impression que deux pointeurs suffisent mais je me trompe peut-être.
http://www.codeproject.com/cpp/FastDelegate.asp Regardes le paragraphe "Implementation of member functions pointers".
[...] l'héritage multiple d'interfaces est autorisé [...]
À partir du moment où l'héritage multiple d'interfaces est autorisé, je me demande quelles complications additionnelles il y aurait dans les pointeurs vers membres avec un héritage multiple plus général.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Loïc Joly
Jean-Marc Bourguet wrote:
À partir du moment où l'héritage multiple d'interfaces est autorisé, je me demande quelles complications additionnelles il y aurait dans les pointeurs vers membres avec un héritage multiple plus général.
Il n'y a pas de décalage à faire lors de conversion depuis un pointeur sur dérivé vers un pointeur sur base quand seul l'héritage multiple d'interface est autorisé.
-- Loïc
Jean-Marc Bourguet wrote:
À partir du moment où l'héritage multiple d'interfaces est autorisé,
je me demande quelles complications additionnelles il y aurait dans
les pointeurs vers membres avec un héritage multiple plus général.
Il n'y a pas de décalage à faire lors de conversion depuis un pointeur
sur dérivé vers un pointeur sur base quand seul l'héritage multiple
d'interface est autorisé.
À partir du moment où l'héritage multiple d'interfaces est autorisé, je me demande quelles complications additionnelles il y aurait dans les pointeurs vers membres avec un héritage multiple plus général.
Il n'y a pas de décalage à faire lors de conversion depuis un pointeur sur dérivé vers un pointeur sur base quand seul l'héritage multiple d'interface est autorisé.
-- Loïc
Arnaud Debaene
Loïc Joly wrote:
Jean-Marc Bourguet wrote:
À partir du moment où l'héritage multiple d'interfaces est autorisé, je me demande quelles complications additionnelles il y aurait dans les pointeurs vers membres avec un héritage multiple plus général.
Il n'y a pas de décalage à faire lors de conversion depuis un pointeur sur dérivé vers un pointeur sur base quand seul l'héritage multiple d'interface est autorisé.
Et l'héritage d'interfaces ne pose pas non plus le problème de l'héritage en diamant et donc de l'héritage virtuel.
Arnaud
Loïc Joly wrote:
Jean-Marc Bourguet wrote:
À partir du moment où l'héritage multiple d'interfaces est autorisé,
je me demande quelles complications additionnelles il y aurait dans
les pointeurs vers membres avec un héritage multiple plus général.
Il n'y a pas de décalage à faire lors de conversion depuis un pointeur
sur dérivé vers un pointeur sur base quand seul l'héritage multiple
d'interface est autorisé.
Et l'héritage d'interfaces ne pose pas non plus le problème de l'héritage en
diamant et donc de l'héritage virtuel.
À partir du moment où l'héritage multiple d'interfaces est autorisé, je me demande quelles complications additionnelles il y aurait dans les pointeurs vers membres avec un héritage multiple plus général.
Il n'y a pas de décalage à faire lors de conversion depuis un pointeur sur dérivé vers un pointeur sur base quand seul l'héritage multiple d'interface est autorisé.
Et l'héritage d'interfaces ne pose pas non plus le problème de l'héritage en diamant et donc de l'héritage virtuel.
Arnaud
Arnaud Debaene
Jean-Marc Bourguet wrote:
"Arnaud Debaene" writes:
5.2.9/8 : oui, sous certaines conditions. En re-regardant, tu voulais sans doute dire 5.2.9/9, mais il s'agit de
"pointer to member", pas de "pointer to member function". Personnellement, je n'ai rien pu trouver concernant les conversions de pointeurs vers fonction membre sauf 5.2.10/9 et je n'ai pas compris l'intérêt de cette clause. J'ai peut être mal cherché?
<snip>
Les langages n'ayant pas d'héritage multiple voient une hiérarchie avec de l'héritage simple. Rien à mettre à jour où je ne te comprends pas. Et quelle est la classe de mère que tu choisis comme étant "visible"? Tu ne
peux pas appeler les méthodes héritées des classes de bases "non visibles"? Je suis curieux de voir comment tu ferais çà.
D'autre part, ca ne rentre pas dans le modèle d'introspection de .NET (que l'on pourrait faire évoluer, d'accord, "yapluka" le faire, bon courage! Je te rappelle que tous ces éléments de .NET sont normalisés).
Enfin, tu ne tiens compte que de l'aspect visible de l'héritage, pas de son implémentation. La grosse différence avec l'héritage multiple, c'est qu'un seul et même objet peut avoir plusieurs adresses différentes selon la "facette" (la classe de base) par laquelle tu le regardes. Comment tu fais pour faire interagir cela avec le garbage collector et le mécanisme de références de .NET?
et de toute façon, je ne pense pas que ça corresponde à la "philosophie" .NET, qui est d'interdire l'héritage multiple d'implémentation car elle est souvent mal utilisée (conceptions objet foireuses qui utilisent l'héritage multiple à la place de l'aggrégation).
As-tu un pointeur vers un document décrivant la "philosophie" .NET, expliquant les choix faits et leurs raisons? Non, c'est mon impression personnelle uniquement (et je la partage!).
Impression malgré tout renforcée par quelques conférences de gars de chez MS auquelles j'ai pu assister, pour ce que ca vaut ;-)
As-tu une définition d'un "bon usage" de l'héritage multiple? Y at'il consensus dessus? Certainement pas, par contre je peux te citer des dizaines de cas de
mauvaise utilisation sans aucun problème. Exemple sur microsoft.public.fr.dotnet, un gars qui tenait absolument à nous faire comprendre que l'héritage multiple d'implémentation, c'est génial parce que s'il a une classe oiseau et une classe cheval, il lui suffit d'hériter des 2 pour faire une classe pégase ;-) Jusqu'à ce qu'on lui fasse remarquer que son pégase pondait des oeufs...
C'est un exemple caricatural (le gars était limite troll), mais pour des développeurs avec peu d'expérience en conception objet, l'héritage multiple est souvent faussement "simple" et sur-utilisé. Je pense que tous les gens avec une expérience de l'enseignement de la POO seront d'accord pour dire que les débutants ont tendance à trop utiliser l'héritage et pas assez l'aggrégation, jusqu'à ce que le principe de substitution de Liskov leur soit rentré dans le crane. L'héritage multiple ne fait qu'empirer cela.
Maintenant, savoir si c'est un argument valide pour interdire l'héritage multiple, je n'en sais rien (personnellement, je regrette qu'il ne soit pas présent dans .NET), mais je peux comprendre les raisons de ce choix, à défaut de les approuver totalement.
5.2.9/8 : oui, sous certaines conditions.
En re-regardant, tu voulais sans doute dire 5.2.9/9, mais il s'agit de
"pointer to member", pas de "pointer to member function".
Personnellement, je n'ai rien pu trouver concernant les conversions de
pointeurs vers fonction membre sauf 5.2.10/9 et je n'ai pas compris
l'intérêt de cette clause. J'ai peut être mal cherché?
<snip>
Les langages n'ayant pas d'héritage multiple voient une
hiérarchie avec de l'héritage simple. Rien à mettre à jour
où je ne te comprends pas.
Et quelle est la classe de mère que tu choisis comme étant "visible"? Tu ne
peux pas appeler les méthodes héritées des classes de bases "non visibles"?
Je suis curieux de voir comment tu ferais çà.
D'autre part, ca ne rentre pas dans le modèle d'introspection de .NET (que
l'on pourrait faire évoluer, d'accord, "yapluka" le faire, bon courage! Je
te rappelle que tous ces éléments de .NET sont normalisés).
Enfin, tu ne tiens compte que de l'aspect visible de l'héritage, pas de son
implémentation. La grosse différence avec l'héritage multiple, c'est qu'un
seul et même objet peut avoir plusieurs adresses différentes selon la
"facette" (la classe de base) par laquelle tu le regardes. Comment tu fais
pour faire interagir cela avec le garbage collector et le mécanisme de
références de .NET?
et de toute façon, je ne pense pas que ça corresponde à la
"philosophie" .NET, qui est d'interdire l'héritage
multiple d'implémentation car elle est souvent mal
utilisée (conceptions objet foireuses qui utilisent
l'héritage multiple à la place de l'aggrégation).
As-tu un pointeur vers un document décrivant la
"philosophie" .NET, expliquant les choix faits et leurs
raisons?
Non, c'est mon impression personnelle uniquement (et je la partage!).
Impression malgré tout renforcée par quelques conférences de gars de chez MS
auquelles j'ai pu assister, pour ce que ca vaut ;-)
As-tu une définition d'un "bon usage" de l'héritage
multiple? Y at'il consensus dessus?
Certainement pas, par contre je peux te citer des dizaines de cas de
mauvaise utilisation sans aucun problème. Exemple sur
microsoft.public.fr.dotnet, un gars qui tenait absolument à nous faire
comprendre que l'héritage multiple d'implémentation, c'est génial parce que
s'il a une classe oiseau et une classe cheval, il lui suffit d'hériter des 2
pour faire une classe pégase ;-) Jusqu'à ce qu'on lui fasse remarquer que
son pégase pondait des oeufs...
C'est un exemple caricatural (le gars était limite troll), mais pour des
développeurs avec peu d'expérience en conception objet, l'héritage multiple
est souvent faussement "simple" et sur-utilisé. Je pense que tous les gens
avec une expérience de l'enseignement de la POO seront d'accord pour dire
que les débutants ont tendance à trop utiliser l'héritage et pas assez
l'aggrégation, jusqu'à ce que le principe de substitution de Liskov leur
soit rentré dans le crane. L'héritage multiple ne fait qu'empirer cela.
Maintenant, savoir si c'est un argument valide pour interdire l'héritage
multiple, je n'en sais rien (personnellement, je regrette qu'il ne soit pas
présent dans .NET), mais je peux comprendre les raisons de ce choix, à
défaut de les approuver totalement.
5.2.9/8 : oui, sous certaines conditions. En re-regardant, tu voulais sans doute dire 5.2.9/9, mais il s'agit de
"pointer to member", pas de "pointer to member function". Personnellement, je n'ai rien pu trouver concernant les conversions de pointeurs vers fonction membre sauf 5.2.10/9 et je n'ai pas compris l'intérêt de cette clause. J'ai peut être mal cherché?
<snip>
Les langages n'ayant pas d'héritage multiple voient une hiérarchie avec de l'héritage simple. Rien à mettre à jour où je ne te comprends pas. Et quelle est la classe de mère que tu choisis comme étant "visible"? Tu ne
peux pas appeler les méthodes héritées des classes de bases "non visibles"? Je suis curieux de voir comment tu ferais çà.
D'autre part, ca ne rentre pas dans le modèle d'introspection de .NET (que l'on pourrait faire évoluer, d'accord, "yapluka" le faire, bon courage! Je te rappelle que tous ces éléments de .NET sont normalisés).
Enfin, tu ne tiens compte que de l'aspect visible de l'héritage, pas de son implémentation. La grosse différence avec l'héritage multiple, c'est qu'un seul et même objet peut avoir plusieurs adresses différentes selon la "facette" (la classe de base) par laquelle tu le regardes. Comment tu fais pour faire interagir cela avec le garbage collector et le mécanisme de références de .NET?
et de toute façon, je ne pense pas que ça corresponde à la "philosophie" .NET, qui est d'interdire l'héritage multiple d'implémentation car elle est souvent mal utilisée (conceptions objet foireuses qui utilisent l'héritage multiple à la place de l'aggrégation).
As-tu un pointeur vers un document décrivant la "philosophie" .NET, expliquant les choix faits et leurs raisons? Non, c'est mon impression personnelle uniquement (et je la partage!).
Impression malgré tout renforcée par quelques conférences de gars de chez MS auquelles j'ai pu assister, pour ce que ca vaut ;-)
As-tu une définition d'un "bon usage" de l'héritage multiple? Y at'il consensus dessus? Certainement pas, par contre je peux te citer des dizaines de cas de
mauvaise utilisation sans aucun problème. Exemple sur microsoft.public.fr.dotnet, un gars qui tenait absolument à nous faire comprendre que l'héritage multiple d'implémentation, c'est génial parce que s'il a une classe oiseau et une classe cheval, il lui suffit d'hériter des 2 pour faire une classe pégase ;-) Jusqu'à ce qu'on lui fasse remarquer que son pégase pondait des oeufs...
C'est un exemple caricatural (le gars était limite troll), mais pour des développeurs avec peu d'expérience en conception objet, l'héritage multiple est souvent faussement "simple" et sur-utilisé. Je pense que tous les gens avec une expérience de l'enseignement de la POO seront d'accord pour dire que les débutants ont tendance à trop utiliser l'héritage et pas assez l'aggrégation, jusqu'à ce que le principe de substitution de Liskov leur soit rentré dans le crane. L'héritage multiple ne fait qu'empirer cela.
Maintenant, savoir si c'est un argument valide pour interdire l'héritage multiple, je n'en sais rien (personnellement, je regrette qu'il ne soit pas présent dans .NET), mais je peux comprendre les raisons de ce choix, à défaut de les approuver totalement.
