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.
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.
En fait, ce serait plutôt ce qui devrait remplacer Managed C++, ce n'est pas compatible du tout, alors difficile de dire que c'est la nouvelle version. C'est la nouvelle version de C++ modifié pour permettre de faire du .NET facilement.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:cfre1m$ntr$1@news-reader5.wanadoo.fr, Loïc
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.
En fait, ce serait plutôt ce qui devrait remplacer Managed C++,
ce n'est pas compatible du tout, alors difficile de dire que
c'est la nouvelle version. C'est la nouvelle version de C++
modifié pour permettre de faire du .NET facilement.
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
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.
En fait, ce serait plutôt ce qui devrait remplacer Managed C++, ce n'est pas compatible du tout, alors difficile de dire que c'est la nouvelle version. C'est la nouvelle version de C++ modifié pour permettre de faire du .NET facilement.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Michel Michaud
Dans news:cfsb5g$vga$, M.
Effectivement, avec le nouveau C++/CLI, dont j'ignorais l'annonce, les choses s'arrangent tres nettement pour le C++ sur .NET
Il y aura a nouveau un interet certain a utiliser C++ sur .NET
En fait, C++ deviendra (redeviendra ?) le langage de choix pour développer pour la plate-forme de MS... et d'ailleurs (voir Mono).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:cfsb5g$vga$1@news-reader2.wanadoo.fr, M.
Effectivement, avec le nouveau C++/CLI, dont j'ignorais
l'annonce, les choses s'arrangent tres nettement pour le C++
sur .NET
Il y aura a nouveau un interet certain a utiliser C++ sur .NET
En fait, C++ deviendra (redeviendra ?) le langage de choix pour
développer pour la plate-forme de MS... et d'ailleurs (voir Mono).
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Effectivement, avec le nouveau C++/CLI, dont j'ignorais l'annonce, les choses s'arrangent tres nettement pour le C++ sur .NET
Il y aura a nouveau un interet certain a utiliser C++ sur .NET
En fait, C++ deviendra (redeviendra ?) le langage de choix pour développer pour la plate-forme de MS... et d'ailleurs (voir Mono).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
M. B.
"Michel Michaud" a écrit dans le message de news: sZzUc.19898$
Dans news:cfsb5g$vga$, M.
Effectivement, avec le nouveau C++/CLI, dont j'ignorais l'annonce, les choses s'arrangent tres nettement pour le C++ sur .NET
Il y aura a nouveau un interet certain a utiliser C++ sur .NET
En fait, C++ deviendra (redeviendra ?) le langage de choix pour développer pour la plate-forme de MS... et d'ailleurs (voir Mono).
Certes. Mais les autres langages evoluent egalement sur .NET Javascript (JScript) support a present l'heritage, VB support les types generiques, etc ...
Ne va-t-on pas, a terme, vers une equivalence stricte de tous les langages sur .NET ?
MB
"Michel Michaud" <mm@gdzid.com> a écrit dans le message de news:
sZzUc.19898$Tr.916797@news20.bellglobal.com...
Dans news:cfsb5g$vga$1@news-reader2.wanadoo.fr, M.
Effectivement, avec le nouveau C++/CLI, dont j'ignorais
l'annonce, les choses s'arrangent tres nettement pour le C++
sur .NET
Il y aura a nouveau un interet certain a utiliser C++ sur .NET
En fait, C++ deviendra (redeviendra ?) le langage de choix pour
développer pour la plate-forme de MS... et d'ailleurs (voir Mono).
Certes. Mais les autres langages evoluent egalement sur .NET
Javascript (JScript) support a present l'heritage, VB support
les types generiques, etc ...
Ne va-t-on pas, a terme, vers une equivalence stricte de tous
les langages sur .NET ?
"Michel Michaud" a écrit dans le message de news: sZzUc.19898$
Dans news:cfsb5g$vga$, M.
Effectivement, avec le nouveau C++/CLI, dont j'ignorais l'annonce, les choses s'arrangent tres nettement pour le C++ sur .NET
Il y aura a nouveau un interet certain a utiliser C++ sur .NET
En fait, C++ deviendra (redeviendra ?) le langage de choix pour développer pour la plate-forme de MS... et d'ailleurs (voir Mono).
Certes. Mais les autres langages evoluent egalement sur .NET Javascript (JScript) support a present l'heritage, VB support les types generiques, etc ...
Ne va-t-on pas, a terme, vers une equivalence stricte de tous les langages sur .NET ?
MB
Michel Michaud
Dans news:cfum3d$kb4$, M.
"Michel Michaud" a écrit dans le message de news: sZzUc.19898$
En fait, C++ deviendra (redeviendra ?) le langage de choix pour développer pour la plate-forme de MS... et d'ailleurs (voir Mono).
Certes. Mais les autres langages evoluent egalement sur .NET Javascript (JScript) support a present l'heritage, VB support les types generiques, etc ...
Donc en attendant 5 ou 10 ans, on pourra faire avec VB ce qu'on peut faire aujourd'hui avec C++ ? Si tu peux attendre... :-)
Ne va-t-on pas, a terme, vers une equivalence stricte de tous les langages sur .NET ?
Non, car C++ est le seul qui existe aussi (et très bien) en dehors de .NET comme langage de développement sérieux pour de multiples usages... (sans compter toutes les choses de C++ qui ne seront pas ajoutées aux autres langages)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:cfum3d$kb4$1@news-reader5.wanadoo.fr, M.
"Michel Michaud" <mm@gdzid.com> a écrit dans le message de news:
sZzUc.19898$Tr.916797@news20.bellglobal.com...
En fait, C++ deviendra (redeviendra ?) le langage de choix pour
développer pour la plate-forme de MS... et d'ailleurs (voir
Mono).
Certes. Mais les autres langages evoluent egalement sur .NET
Javascript (JScript) support a present l'heritage, VB support
les types generiques, etc ...
Donc en attendant 5 ou 10 ans, on pourra faire avec VB ce qu'on
peut faire aujourd'hui avec C++ ? Si tu peux attendre... :-)
Ne va-t-on pas, a terme, vers une equivalence stricte de tous
les langages sur .NET ?
Non, car C++ est le seul qui existe aussi (et très bien) en
dehors de .NET comme langage de développement sérieux pour de
multiples usages... (sans compter toutes les choses de C++ qui
ne seront pas ajoutées aux autres langages)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
"Michel Michaud" a écrit dans le message de news: sZzUc.19898$
En fait, C++ deviendra (redeviendra ?) le langage de choix pour développer pour la plate-forme de MS... et d'ailleurs (voir Mono).
Certes. Mais les autres langages evoluent egalement sur .NET Javascript (JScript) support a present l'heritage, VB support les types generiques, etc ...
Donc en attendant 5 ou 10 ans, on pourra faire avec VB ce qu'on peut faire aujourd'hui avec C++ ? Si tu peux attendre... :-)
Ne va-t-on pas, a terme, vers une equivalence stricte de tous les langages sur .NET ?
Non, car C++ est le seul qui existe aussi (et très bien) en dehors de .NET comme langage de développement sérieux pour de multiples usages... (sans compter toutes les choses de C++ qui ne seront pas ajoutées aux autres langages)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Arnaud Debaene
Jean-Marc Bourguet wrote:
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.
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!
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!), 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). Par ailleurs, cela encourage à la programmation par interface (vu que l'héritage multiple d'interfaces est autorisé - oui, je sais que les interfaces .NET ou Java sont notoirement insuffisantes ;-)
PS : C'est *mon* interprétation des choix de MS -:)
Arnaud
Jean-Marc Bourguet wrote:
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.
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!
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!), 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). Par ailleurs, cela
encourage à la programmation par interface (vu que l'héritage multiple
d'interfaces est autorisé - oui, je sais que les interfaces .NET ou Java
sont notoirement insuffisantes ;-)
PS : C'est *mon* interprétation des choix de MS -:)
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.
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!
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!), 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). Par ailleurs, cela encourage à la programmation par interface (vu que l'héritage multiple d'interfaces est autorisé - oui, je sais que les interfaces .NET ou Java sont notoirement insuffisantes ;-)
PS : C'est *mon* interprétation des choix de MS -:)
Arnaud
Arnaud Debaene
M. B. wrote:
"drkm" a écrit dans le message de news:
Loïc Joly writes:
- Si on veut que le développeur en VB puisse utiliser le template vector qu'il instancie pour les types de son choix
Sauf que les génériques .NET ne sont pas les templates. C'est un autre approche qui présente certains intérêt, mais qui est quand même clairement moins puissante que les templates.
Arnaud
M. B. wrote:
"drkm" <usenet.fclcxx@fgeorges.org> a écrit dans le message de news:
wkr7q5fjre.fsf_-_@fgeorges.org...
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
- Si on veut que le développeur en VB puisse utiliser le template
vector qu'il instancie pour les types de son choix
Sauf que les génériques .NET ne sont pas les templates. C'est un autre
approche qui présente certains intérêt, mais qui est quand même clairement
moins puissante que les templates.
Sauf que les génériques .NET ne sont pas les templates. C'est un autre approche qui présente certains intérêt, mais qui est quand même clairement moins puissante que les templates.
Arnaud
Gabriel Dos Reis
"Michel Michaud" writes:
| Dans news:cfsb5g$vga$, M. | > Effectivement, avec le nouveau C++/CLI, dont j'ignorais | > l'annonce, les choses s'arrangent tres nettement pour le C++ | > sur .NET | > | > Il y aura a nouveau un interet certain a utiliser C++ sur .NET | | En fait, C++ deviendra (redeviendra ?) le langage de choix pour | développer pour la plate-forme de MS... et d'ailleurs (voir Mono).
D'apres des sources surs, MS ne requiert plus, pour ses employes, C# comme langage de developpement ; en fait C++ est de nouveau tres encourage pour developper de nouveaux projets. Comprenne qui pourra.
-- Gaby
"Michel Michaud" <mm@gdzid.com> writes:
| Dans news:cfsb5g$vga$1@news-reader2.wanadoo.fr, M.
| > Effectivement, avec le nouveau C++/CLI, dont j'ignorais
| > l'annonce, les choses s'arrangent tres nettement pour le C++
| > sur .NET
| >
| > Il y aura a nouveau un interet certain a utiliser C++ sur .NET
|
| En fait, C++ deviendra (redeviendra ?) le langage de choix pour
| développer pour la plate-forme de MS... et d'ailleurs (voir Mono).
D'apres des sources surs, MS ne requiert plus, pour ses employes, C#
comme langage de developpement ; en fait C++ est de nouveau tres
encourage pour developper de nouveaux projets.
Comprenne qui pourra.
| Dans news:cfsb5g$vga$, M. | > Effectivement, avec le nouveau C++/CLI, dont j'ignorais | > l'annonce, les choses s'arrangent tres nettement pour le C++ | > sur .NET | > | > Il y aura a nouveau un interet certain a utiliser C++ sur .NET | | En fait, C++ deviendra (redeviendra ?) le langage de choix pour | développer pour la plate-forme de MS... et d'ailleurs (voir Mono).
D'apres des sources surs, MS ne requiert plus, pour ses employes, C# comme langage de developpement ; en fait C++ est de nouveau tres encourage pour developper de nouveaux projets. Comprenne qui pourra.
-- Gaby
Michel Michaud
Dans news:, Gabriel
D'apres des sources surs, MS ne requiert plus, pour ses employes, C# comme langage de developpement ; en fait C++ est de nouveau tres encourage pour developper de nouveaux projets. Comprenne qui pourra.
Je ne vois pas ce qui est difficile à comprendre :
« Cool ! Un nouveau langage ! Il doit être vraiment mieux que notre vieux C++ ! On va réussir à faire nos projets en moins de temps et de meilleure qualité ! Essayons-le ! »
... (le temps passe et les expériences aussi)
« Bon, rien ne vaut notre bon vieux C++ ! On y retourne ! »
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:m33c2kunax.fsf@uniton.integrable-solutions.net, Gabriel
D'apres des sources surs, MS ne requiert plus, pour ses
employes, C# comme langage de developpement ; en fait C++ est
de nouveau tres encourage pour developper de nouveaux projets.
Comprenne qui pourra.
Je ne vois pas ce qui est difficile à comprendre :
« Cool ! Un nouveau langage ! Il doit être vraiment mieux que
notre vieux C++ ! On va réussir à faire nos projets en moins
de temps et de meilleure qualité ! Essayons-le ! »
... (le temps passe et les expériences aussi)
« Bon, rien ne vaut notre bon vieux C++ ! On y retourne ! »
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
D'apres des sources surs, MS ne requiert plus, pour ses employes, C# comme langage de developpement ; en fait C++ est de nouveau tres encourage pour developper de nouveaux projets. Comprenne qui pourra.
Je ne vois pas ce qui est difficile à comprendre :
« Cool ! Un nouveau langage ! Il doit être vraiment mieux que notre vieux C++ ! On va réussir à faire nos projets en moins de temps et de meilleure qualité ! Essayons-le ! »
... (le temps passe et les expériences aussi)
« Bon, rien ne vaut notre bon vieux C++ ! On y retourne ! »
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
