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.
M. B. wrote: Il n'y a aucun interet a utiliser C++ sur .NET
Ah bon ? Et pourquoi ? En fait, moi je ne vois pas l'intérêt d'utiliser VB ou C# sur .NET puisque C++ est aussi utilisable. Et avec le nouveau CLI-C++, il y aura encore plus de raisons de ne pas se priver des avantages de C++.
Ou alors tu voulais dire qu'il n'y avait pas d'intérêt à utiliser .NET ? Tu as raison, la seule raison d'utiliser .NET est si ton patron te le demande... Hum. C'est une bien bonne raison tiens...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
M. B. wrote:
Il n'y a aucun interet a utiliser C++ sur .NET
Ah bon ? Et pourquoi ? En fait, moi je ne vois pas l'intérêt
d'utiliser VB ou C# sur .NET puisque C++ est aussi utilisable.
Et avec le nouveau CLI-C++, il y aura encore plus de raisons
de ne pas se priver des avantages de C++.
Ou alors tu voulais dire qu'il n'y avait pas d'intérêt à
utiliser .NET ? Tu as raison, la seule raison d'utiliser .NET
est si ton patron te le demande... Hum. C'est une bien bonne
raison tiens...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
M. B. wrote: Il n'y a aucun interet a utiliser C++ sur .NET
Ah bon ? Et pourquoi ? En fait, moi je ne vois pas l'intérêt d'utiliser VB ou C# sur .NET puisque C++ est aussi utilisable. Et avec le nouveau CLI-C++, il y aura encore plus de raisons de ne pas se priver des avantages de C++.
Ou alors tu voulais dire qu'il n'y avait pas d'intérêt à utiliser .NET ? Tu as raison, la seule raison d'utiliser .NET est si ton patron te le demande... Hum. C'est une bien bonne raison tiens...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
drkm
"Michel Michaud" writes:
Et avec le nouveau CLI-C++
Tiens. J'ai déjà vu ce terme quelques fois. Qu'est-ce ?
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
"Michel Michaud" <mm@gdzid.com> writes:
Et avec le nouveau CLI-C++
Tiens. J'ai déjà vu ce terme quelques fois. Qu'est-ce ?
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Tiens. J'ai déjà vu ce terme quelques fois. Qu'est-ce ?
C'est la nouvelle version de ce qui s'appelait managed C++ avec VC++7.0.
Tiens. J'ai déjà vu ce terme quelques fois. Qu'est-ce ?-)
Avec Visual studio.NET, Microsoft a défini un langage bas niveau, mais comprenant quand même des notions d'objet. Quand on programme, par exemple en VB.NET ou en C#.NET, le code est compilé vers ce langage intermédiaire, et c'est celui-ci qui est exécuté par le CLR (common language runtime).
Ca permet entre autre de faire un programme inter-langages aisément, et comme la spec CLR est publique, d'autres personnes peuvent interfacer leur langage aussi. Jenre je dérive en VB d'une classe définie en C#.
L'idée est que dans un programme, l'historique soit en cobol, la partie hard et demandant des perfs en C++, et l'IHM en C# ou en VB.
Que vient faire le C++ justement là dedans ?
Pour rendre le VB compatible CLR, c'est simple, il a suffit de lui ajouter des fonctions, comme par exemple la possibilité de définir des classes (avant, en VB, on ne pouvait qu'utiliser des classes définies par d'autres). Pour le C#, encore plus simple, le langage a été conçu avec la CLR en tête.
Pour le C++, la situation n'est pas si simple : D'abbord, c'est un langage public et avec d'autres implémentations, donc microsoft ne peut pas le modifier à sa guise, sous peine de perdre le code existant. Et il ne rentre pas bien dans la CLR, qui est plus d'un niveau JAVA (elle ne comprend pas les templates, l'héritage multiple...).
Donc, Microsoft a défini un langage appelé C++ managé, qui a la double particularité d'être compatible CLR et C++. En pratique, ça permet d'écrire du code en "mauvais C++" qui permet de faire le lien entre du code C++ et la CLR.
Le principal problème de managed C++, AMA, c'est justement que bien que compatible C++, il oblige une lourdeur syntaxique extrème ppour le développeur C++, et ses idiomes vont à l'encontre des idiomes C++ classiques (par exemple, tout est pointeur, tout est forcément garbage collecté...).
Je n'ai pas trop suivi CLI-C++, mais à ce que j'en ai compris, ça part e l'idée de reprendre l'intégration du C++ dans l'ensemble, en particulier en agissant sur 3 points : - Augmenter la CLR pour ne plus autant niveler par le bas - Permettre du code plus élégant en CLI-C++ qu'en Managed C++ (notion de type non garbage collecté, permettant le RAII, par exemple) - Eventuellement influencer sur des évolutions de la norme C++.
Si tu veux plus d'info, je te conseille google avec Herb Sutter, puisqu'il semble être le porte-parole de Microsoft sur le sujet.
-- Loïc
drkm wrote:
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
drkm wrote:
"Michel Michaud" <mm@gdzid.com> writes:
Et avec le nouveau CLI-C++
Tiens. J'ai déjà vu ce terme quelques fois. Qu'est-ce ?
C'est la nouvelle version de ce qui s'appelait managed C++ avec VC++7.0.
Tiens. J'ai déjà vu ce terme quelques fois. Qu'est-ce ?-)
Avec Visual studio.NET, Microsoft a défini un langage bas niveau, mais
comprenant quand même des notions d'objet. Quand on programme, par
exemple en VB.NET ou en C#.NET, le code est compilé vers ce langage
intermédiaire, et c'est celui-ci qui est exécuté par le CLR (common
language runtime).
Ca permet entre autre de faire un programme inter-langages aisément, et
comme la spec CLR est publique, d'autres personnes peuvent interfacer
leur langage aussi. Jenre je dérive en VB d'une classe définie en C#.
L'idée est que dans un programme, l'historique soit en cobol, la partie
hard et demandant des perfs en C++, et l'IHM en C# ou en VB.
Que vient faire le C++ justement là dedans ?
Pour rendre le VB compatible CLR, c'est simple, il a suffit de lui
ajouter des fonctions, comme par exemple la possibilité de définir des
classes (avant, en VB, on ne pouvait qu'utiliser des classes définies
par d'autres). Pour le C#, encore plus simple, le langage a été conçu
avec la CLR en tête.
Pour le C++, la situation n'est pas si simple : D'abbord, c'est un
langage public et avec d'autres implémentations, donc microsoft ne peut
pas le modifier à sa guise, sous peine de perdre le code existant. Et il
ne rentre pas bien dans la CLR, qui est plus d'un niveau JAVA (elle ne
comprend pas les templates, l'héritage multiple...).
Donc, Microsoft a défini un langage appelé C++ managé, qui a la double
particularité d'être compatible CLR et C++. En pratique, ça permet
d'écrire du code en "mauvais C++" qui permet de faire le lien entre du
code C++ et la CLR.
Le principal problème de managed C++, AMA, c'est justement que bien que
compatible C++, il oblige une lourdeur syntaxique extrème ppour le
développeur C++, et ses idiomes vont à l'encontre des idiomes C++
classiques (par exemple, tout est pointeur, tout est forcément garbage
collecté...).
Je n'ai pas trop suivi CLI-C++, mais à ce que j'en ai compris, ça part e
l'idée de reprendre l'intégration du C++ dans l'ensemble, en particulier
en agissant sur 3 points :
- Augmenter la CLR pour ne plus autant niveler par le bas
- Permettre du code plus élégant en CLI-C++ qu'en Managed C++ (notion de
type non garbage collecté, permettant le RAII, par exemple)
- Eventuellement influencer sur des évolutions de la norme C++.
Si tu veux plus d'info, je te conseille google avec Herb Sutter,
puisqu'il semble être le porte-parole de Microsoft sur le sujet.
Tiens. J'ai déjà vu ce terme quelques fois. Qu'est-ce ?
C'est la nouvelle version de ce qui s'appelait managed C++ avec VC++7.0.
Tiens. J'ai déjà vu ce terme quelques fois. Qu'est-ce ?-)
Avec Visual studio.NET, Microsoft a défini un langage bas niveau, mais comprenant quand même des notions d'objet. Quand on programme, par exemple en VB.NET ou en C#.NET, le code est compilé vers ce langage intermédiaire, et c'est celui-ci qui est exécuté par le CLR (common language runtime).
Ca permet entre autre de faire un programme inter-langages aisément, et comme la spec CLR est publique, d'autres personnes peuvent interfacer leur langage aussi. Jenre je dérive en VB d'une classe définie en C#.
L'idée est que dans un programme, l'historique soit en cobol, la partie hard et demandant des perfs en C++, et l'IHM en C# ou en VB.
Que vient faire le C++ justement là dedans ?
Pour rendre le VB compatible CLR, c'est simple, il a suffit de lui ajouter des fonctions, comme par exemple la possibilité de définir des classes (avant, en VB, on ne pouvait qu'utiliser des classes définies par d'autres). Pour le C#, encore plus simple, le langage a été conçu avec la CLR en tête.
Pour le C++, la situation n'est pas si simple : D'abbord, c'est un langage public et avec d'autres implémentations, donc microsoft ne peut pas le modifier à sa guise, sous peine de perdre le code existant. Et il ne rentre pas bien dans la CLR, qui est plus d'un niveau JAVA (elle ne comprend pas les templates, l'héritage multiple...).
Donc, Microsoft a défini un langage appelé C++ managé, qui a la double particularité d'être compatible CLR et C++. En pratique, ça permet d'écrire du code en "mauvais C++" qui permet de faire le lien entre du code C++ et la CLR.
Le principal problème de managed C++, AMA, c'est justement que bien que compatible C++, il oblige une lourdeur syntaxique extrème ppour le développeur C++, et ses idiomes vont à l'encontre des idiomes C++ classiques (par exemple, tout est pointeur, tout est forcément garbage collecté...).
Je n'ai pas trop suivi CLI-C++, mais à ce que j'en ai compris, ça part e l'idée de reprendre l'intégration du C++ dans l'ensemble, en particulier en agissant sur 3 points : - Augmenter la CLR pour ne plus autant niveler par le bas - Permettre du code plus élégant en CLI-C++ qu'en Managed C++ (notion de type non garbage collecté, permettant le RAII, par exemple) - Eventuellement influencer sur des évolutions de la norme C++.
Si tu veux plus d'info, je te conseille google avec Herb Sutter, puisqu'il semble être le porte-parole de Microsoft sur le sujet.
-- Loïc
Jean-Marc Bourguet
Loïc Joly writes:
Pour le C++, la situation n'est pas si simple : [...]. Et il ne rentre pas bien dans la CLR, qui est plus d'un niveau JAVA (elle ne comprend pas les templates, l'héritage multiple...).
Je comprends pas ces problemes. Les templates en C++ fonctionnant essentiellement a la maniere de macros integrees dans le systeme de typage, il n'a pas besoin que le langage cible les comprennent. Et faire de l'heritage multiple quand on connait l'heritage simple, c'est pas si complique (il faut generer du code, mais c'est qqch que les compilateurs font bien).
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 <loic.actarus.joly@wanadoo.fr> writes:
Pour le C++, la situation n'est pas si simple : [...]. Et il ne
rentre pas bien dans la CLR, qui est plus d'un niveau JAVA (elle ne
comprend pas les templates, l'héritage multiple...).
Je comprends pas ces problemes. Les templates en C++ fonctionnant
essentiellement a la maniere de macros integrees dans le systeme de
typage, il n'a pas besoin que le langage cible les comprennent. Et
faire de l'heritage multiple quand on connait l'heritage simple, c'est
pas si complique (il faut generer du code, mais c'est qqch que les
compilateurs font bien).
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
Pour le C++, la situation n'est pas si simple : [...]. Et il ne rentre pas bien dans la CLR, qui est plus d'un niveau JAVA (elle ne comprend pas les templates, l'héritage multiple...).
Je comprends pas ces problemes. Les templates en C++ fonctionnant essentiellement a la maniere de macros integrees dans le systeme de typage, il n'a pas besoin que le langage cible les comprennent. Et faire de l'heritage multiple quand on connait l'heritage simple, c'est pas si complique (il faut generer du code, mais c'est qqch que les compilateurs font bien).
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:
Loïc Joly writes:
Pour le C++, la situation n'est pas si simple : [...]. Et il ne rentre pas bien dans la CLR, qui est plus d'un niveau JAVA (elle ne comprend pas les templates, l'héritage multiple...).
Je comprends pas ces problemes. Les templates en C++ fonctionnant essentiellement a la maniere de macros integrees dans le systeme de typage, il n'a pas besoin que le langage cible les comprennent.
Ca dépend de ce qu'on veut (il ne faut pas oublier que le langage cible n'est pas uniquement destiné à exécuter le code, mais possède aussi des fonctions d'introspections permettant de l'étendre) : - Si on veut que le développeur en VB puisse utiliser le template vector qu'il instancie pour les types de son choix, il faut que le langage intermédiaire comprenne la notion de template - Si on veut juste qu'il puisse utiliser un vector<int>, ce qui est je pense ce que tu voulais dire, la situation est effectivement plus simple. Il suffit de dfinir un mapping entre vector<int> et un nom de type unique valide (disons vector_int) pour que le gars en VB puisse faire ce qu'il veut de ce type : En créer des variables, en dériver...
Je ne sais pas trop pourquoi la deuxième solution n'a pas été implémentée. Elle ressemblerait en terme d'utilisations possibles en quelque sorte à l'instanciation explicite des templates.
Et faire de l'heritage multiple quand on connait l'heritage simple, c'est pas si complique (il faut generer du code, mais c'est qqch que les compilateurs font bien).
Il me semble que c'est prévu dans CLI-C++.
Globalement, et caricaturalement, j'ai le sentiment que la CLR a été conçue sans que les gars du C++ chez Microsoft soient au courant, et qu'on leur a laissé un temps très court pour s'y adapter et sortir rapidement un produit, et que seulement récemment, il sont vraiment entrés dans la boucle.
-- Loïc
Jean-Marc Bourguet wrote:
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
Pour le C++, la situation n'est pas si simple : [...]. Et il ne
rentre pas bien dans la CLR, qui est plus d'un niveau JAVA (elle ne
comprend pas les templates, l'héritage multiple...).
Je comprends pas ces problemes. Les templates en C++ fonctionnant
essentiellement a la maniere de macros integrees dans le systeme de
typage, il n'a pas besoin que le langage cible les comprennent.
Ca dépend de ce qu'on veut (il ne faut pas oublier que le langage cible
n'est pas uniquement destiné à exécuter le code, mais possède aussi des
fonctions d'introspections permettant de l'étendre) :
- Si on veut que le développeur en VB puisse utiliser le template vector
qu'il instancie pour les types de son choix, il faut que le langage
intermédiaire comprenne la notion de template
- Si on veut juste qu'il puisse utiliser un vector<int>, ce qui est je
pense ce que tu voulais dire, la situation est effectivement plus
simple. Il suffit de dfinir un mapping entre vector<int> et un nom de
type unique valide (disons vector_int) pour que le gars en VB puisse
faire ce qu'il veut de ce type : En créer des variables, en dériver...
Je ne sais pas trop pourquoi la deuxième solution n'a pas été
implémentée. Elle ressemblerait en terme d'utilisations possibles en
quelque sorte à l'instanciation explicite des templates.
Et
faire de l'heritage multiple quand on connait l'heritage simple, c'est
pas si complique (il faut generer du code, mais c'est qqch que les
compilateurs font bien).
Il me semble que c'est prévu dans CLI-C++.
Globalement, et caricaturalement, j'ai le sentiment que la CLR a été
conçue sans que les gars du C++ chez Microsoft soient au courant, et
qu'on leur a laissé un temps très court pour s'y adapter et sortir
rapidement un produit, et que seulement récemment, il sont vraiment
entrés dans la boucle.
Pour le C++, la situation n'est pas si simple : [...]. Et il ne rentre pas bien dans la CLR, qui est plus d'un niveau JAVA (elle ne comprend pas les templates, l'héritage multiple...).
Je comprends pas ces problemes. Les templates en C++ fonctionnant essentiellement a la maniere de macros integrees dans le systeme de typage, il n'a pas besoin que le langage cible les comprennent.
Ca dépend de ce qu'on veut (il ne faut pas oublier que le langage cible n'est pas uniquement destiné à exécuter le code, mais possède aussi des fonctions d'introspections permettant de l'étendre) : - Si on veut que le développeur en VB puisse utiliser le template vector qu'il instancie pour les types de son choix, il faut que le langage intermédiaire comprenne la notion de template - Si on veut juste qu'il puisse utiliser un vector<int>, ce qui est je pense ce que tu voulais dire, la situation est effectivement plus simple. Il suffit de dfinir un mapping entre vector<int> et un nom de type unique valide (disons vector_int) pour que le gars en VB puisse faire ce qu'il veut de ce type : En créer des variables, en dériver...
Je ne sais pas trop pourquoi la deuxième solution n'a pas été implémentée. Elle ressemblerait en terme d'utilisations possibles en quelque sorte à l'instanciation explicite des templates.
Et faire de l'heritage multiple quand on connait l'heritage simple, c'est pas si complique (il faut generer du code, mais c'est qqch que les compilateurs font bien).
Il me semble que c'est prévu dans CLI-C++.
Globalement, et caricaturalement, j'ai le sentiment que la CLR a été conçue sans que les gars du C++ chez Microsoft soient au courant, et qu'on leur a laissé un temps très court pour s'y adapter et sortir rapidement un produit, et que seulement récemment, il sont vraiment entrés dans la boucle.
-- Loïc
Arnaud Debaene
Jean-Marc Bourguet wrote:
Loïc Joly writes:
Pour le C++, la situation n'est pas si simple : [...]. Et il ne rentre pas bien dans la CLR, qui est plus d'un niveau JAVA (elle ne comprend pas les templates, l'héritage multiple...).
Je comprends pas ces problemes. Les templates en C++ fonctionnant essentiellement a la maniere de macros integrees dans le systeme de typage, il n'a pas besoin que le langage cible les comprennent. Tu peux utiliser les templates dans du C++ managé *de manière interne*, mais
tu ne peux pas exposer ces templates au monde .NET (qui ne les comprend pas).
Et faire de l'heritage multiple quand on connait l'heritage simple, c'est pas si complique Là je ne suis pas d'accord : en terme d'implémentation, c'est *beaucoup*
plus compliqué. 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? 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? Il y a des tas de cas tordus dans le genre ad nauseam.
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).
Arnaud
Jean-Marc Bourguet wrote:
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
Pour le C++, la situation n'est pas si simple : [...]. Et il ne
rentre pas bien dans la CLR, qui est plus d'un niveau JAVA (elle ne
comprend pas les templates, l'héritage multiple...).
Je comprends pas ces problemes. Les templates en C++ fonctionnant
essentiellement a la maniere de macros integrees dans le systeme de
typage, il n'a pas besoin que le langage cible les comprennent.
Tu peux utiliser les templates dans du C++ managé *de manière interne*, mais
tu ne peux pas exposer ces templates au monde .NET (qui ne les comprend
pas).
Et
faire de l'heritage multiple quand on connait l'heritage simple, c'est
pas si complique
Là je ne suis pas d'accord : en terme d'implémentation, c'est *beaucoup*
plus compliqué. 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? 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? Il y a des tas de cas tordus dans le genre ad nauseam.
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).
Pour le C++, la situation n'est pas si simple : [...]. Et il ne rentre pas bien dans la CLR, qui est plus d'un niveau JAVA (elle ne comprend pas les templates, l'héritage multiple...).
Je comprends pas ces problemes. Les templates en C++ fonctionnant essentiellement a la maniere de macros integrees dans le systeme de typage, il n'a pas besoin que le langage cible les comprennent. Tu peux utiliser les templates dans du C++ managé *de manière interne*, mais
tu ne peux pas exposer ces templates au monde .NET (qui ne les comprend pas).
Et faire de l'heritage multiple quand on connait l'heritage simple, c'est pas si complique Là je ne suis pas d'accord : en terme d'implémentation, c'est *beaucoup*
plus compliqué. 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? 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? Il y a des tas de cas tordus dans le genre ad nauseam.
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).
Arnaud
Jean-Marc Bourguet
"Arnaud Debaene" writes:
Jean-Marc Bourguet wrote:
Loïc Joly writes:
Pour le C++, la situation n'est pas si simple : [...]. Et il ne rentre pas bien dans la CLR, qui est plus d'un niveau JAVA (elle ne comprend pas les templates, l'héritage multiple...).
Je comprends pas ces problemes. Les templates en C++ fonctionnant essentiellement a la maniere de macros integrees dans le systeme de typage, il n'a pas besoin que le langage cible les comprennent.
Tu peux utiliser les templates dans du C++ managé *de manière interne*, mais tu ne peux pas exposer ces templates au monde .NET (qui ne les comprend pas).
Ok.
Et faire de l'heritage multiple quand on connait l'heritage simple, c'est pas si complique
À nouveau, j'étais dans l'optique d'une implémentation de C++ sur CLR.
Là je ne suis pas d'accord : en terme d'implémentation, c'est *beaucoup* plus compliqué.
C'est plus compliqué que l'héritage simple, ce n'est pas si compliqué que celà. Si tu as une classe C qui hérite des classes A et B, tu définis des classes AC héritant de A et BC héritant de B et la classe C contient les nouveaux membres et des pointeurs vers AC et BC (qui elles-mêmes contiennent des pointeurs vers C). Ensuite il y a quelque détails à résoudre mais ce n'est pas compliqué. Je l'ai fait en Ada à la main (mais quand on le fait à la main, on arrive souvent à simplifier un peu).
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.
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.
Il y a des tas de cas tordus dans le genre ad nauseam.
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.
A+
-- Jean-Marc, absent pendant une semaine, pas réellement le moment de commencer une discussion 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
Pour le C++, la situation n'est pas si simple : [...]. Et il ne
rentre pas bien dans la CLR, qui est plus d'un niveau JAVA (elle ne
comprend pas les templates, l'héritage multiple...).
Je comprends pas ces problemes. Les templates en C++
fonctionnant essentiellement a la maniere de macros
integrees dans le systeme de typage, il n'a pas besoin
que le langage cible les comprennent.
Tu peux utiliser les templates dans du C++ managé *de
manière interne*, mais tu ne peux pas exposer ces
templates au monde .NET (qui ne les comprend pas).
Ok.
Et faire de l'heritage multiple quand on connait
l'heritage simple, c'est pas si complique
À nouveau, j'étais dans l'optique d'une implémentation de
C++ sur CLR.
Là je ne suis pas d'accord : en terme d'implémentation,
c'est *beaucoup* plus compliqué.
C'est plus compliqué que l'héritage simple, ce n'est pas si
compliqué que celà. Si tu as une classe C qui hérite des
classes A et B, tu définis des classes AC héritant de A et
BC héritant de B et la classe C contient les nouveaux
membres et des pointeurs vers AC et BC (qui elles-mêmes
contiennent des pointeurs vers C). Ensuite il y a quelque
détails à résoudre mais ce n'est pas compliqué. Je l'ai
fait en Ada à la main (mais quand on le fait à la main, on
arrive souvent à simplifier un peu).
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.
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.
Il y a des tas de cas tordus dans le genre ad nauseam.
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.
A+
--
Jean-Marc, absent pendant une semaine, pas réellement le
moment de commencer une discussion
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
Pour le C++, la situation n'est pas si simple : [...]. Et il ne rentre pas bien dans la CLR, qui est plus d'un niveau JAVA (elle ne comprend pas les templates, l'héritage multiple...).
Je comprends pas ces problemes. Les templates en C++ fonctionnant essentiellement a la maniere de macros integrees dans le systeme de typage, il n'a pas besoin que le langage cible les comprennent.
Tu peux utiliser les templates dans du C++ managé *de manière interne*, mais tu ne peux pas exposer ces templates au monde .NET (qui ne les comprend pas).
Ok.
Et faire de l'heritage multiple quand on connait l'heritage simple, c'est pas si complique
À nouveau, j'étais dans l'optique d'une implémentation de C++ sur CLR.
Là je ne suis pas d'accord : en terme d'implémentation, c'est *beaucoup* plus compliqué.
C'est plus compliqué que l'héritage simple, ce n'est pas si compliqué que celà. Si tu as une classe C qui hérite des classes A et B, tu définis des classes AC héritant de A et BC héritant de B et la classe C contient les nouveaux membres et des pointeurs vers AC et BC (qui elles-mêmes contiennent des pointeurs vers C). Ensuite il y a quelque détails à résoudre mais ce n'est pas compliqué. Je l'ai fait en Ada à la main (mais quand on le fait à la main, on arrive souvent à simplifier un peu).
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.
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.
Il y a des tas de cas tordus dans le genre ad nauseam.
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.
A+
-- Jean-Marc, absent pendant une semaine, pas réellement le moment de commencer une discussion 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
