Discussion :

[radiant]

Bonjour,

Je re-découvre le forum et le site depuis ses derniers jours et quelque chose me titille, je vois partout que vous parlez du VB.net, du C#, des informations sur le framework .NET…

Cependant, qu’en est-il de C++ .NET ? Si je regarde sur http://dotnet.developpez.com/ , je trouve que 4 sujets sur le C++/CLI dans les actualités !

Qui plus est, dans la barre de droite (toujours sur http://dotnet.developpez.com/ ) on retrouve les champs ASPX, C#, VB et Delphi mais rien sur C++.

Que doit on en conclure ?
C++/CLI est peu voir pas utilisé ?
C++/CLI n’est pas intéressant ?
N’apporte rien d’intéressant face à C# et VB.net ?
Dans le cas contraire, faut il continuer a faire du C++ MFC ou passer en C++/CLI .net ?

Merci d’avance pour vos infos !

[DeusXL]

Je n'en veux pas au C++/CLI (enfin à mon époque c'était le C++ managed si je me souviens bien ) car il m'a permis de découvrir .NET sans changer complètement de langage mais personellement je me suis vite rendu à l'évidence : il ne sert à rien.
Bon d'accord il permet de faire du mixed mode, c'est un atout énorme (reparlez-m'en sur Mono on va rire) mais sa syntaxe est lourde et incompréhensible.
Des progrès ont certes été faits sur la version 2.0 mais c'est toujours trop lourd.
Le C# est le langage principal de .NET, VB .NET est un langage important pour beaucoup, le Delphi aussi... La plupart des afficionados du C++ critiquent .NET avec des arguments ridicules, il n'y a rien d'étonnant à ce que C++/CLI ne fasse pas l'unanimité.

Enfin moi les deux principaux aspects que je lui trouve d'intéressant c'est 1] le mixed mode et 2] le fait de permettre aux programmeurs C++ de passer par un langage intermédiaire. Mis à part ces deux points, je vois pas son utilité.

[JolyLoic]

La plupart des afficionados du C++ critiquent .NET avec des arguments ridicules

Que la critique existe et soit assez forte, pourquoi pas. Que les arguments soient ridicules, je suis près à en discuter... En tant qu'afficionnado du C++ qui utilise .NET, mes principales critiques sont les suivantes :

- Manque d'héritage multiple
- Typage faible obligeant à faire du downcast toutes les trois lignes
- Absense de friend, ce qui oblige à diminuer l'encapsulation
- Absence d'outil d'édition de liens
- Pas de séparation nette possible entre interface et implémentation (les interfaces de .NET sont trop restrictives pour ça).
- Lourdeur de l'outil de design de formulaires

Les principaux points forts que je lui trouve :
- Réflexion
- Très complet sans avoir besoin de bibliothèque tierce.
- Editeurs de code bien pensée (mais est-ce du à la simplicité des langages, qui permet d'avoir de l'intellisense qui marche, du refactoring, ou bien est-ce du à la quantité d'effort passé dans les nouveaux éditeurs par rapport aux anciens ?)


Quand au C++/CLI, je le trouve tellement lourd, complexe (il ajoute la complexité de .NET à celle du C++) et imposant un style de code tellement étranger au C++ moderne, que je ne l'utilise qu'au minimum, pour réaliser la couche d'interface entre le coeur du programme en C++, et l'IHM en .NET.

[radiant]

Merci vous deux, je commence a avoir des idées plus claires cependant, je me pose encore des questions...

Je vais recentrer sur mon problème si vous le voulez bien.

Typiquement on me demande de faire des choix technologique, pour développer rapidement et de façons relativement claire, sans forcément avoir des contraintes de temps (du type temps réel) dans nos programme mais on sera amener à utiliser des instruments de mesures.

Ca fait un an et demi que je programme en C#, mais ça fait un peu peur dans le monde industriel. Les instruments (alim, oscilloscopes) utilisent des DLL codées en C, voir C++.
Et je ne sais pas si ça vaut le coup de coder des wrapers pour l’utiliser avec C#.

Je me rends bien compte que .NET pousse car on aperçois du code C# et VB.net pour contrôler des alimentations (Aglient) via pc, même chose pour d’autres instruments de mesures mais pas tous malheureusement.

Le "standard" de l’entreprise étant le C++, voila pourquoi je cherchais des infos sur C++/CLI qui je supposais m’aurais bien arrangé les choses...

Alors maintenant, que faire…?

Qu'est ce que le:

C++ moderne?

Comment faire du C++ facile à maintenir, simple à lire et à comprendre ?

C'est vrais, mise a part peut être QT, je ne connais pas de framework complet permettant de réaliser facilement thread, communication rs232, impression, etc...

Je suppose que des sous traitants dans le monde industiels codent en C/C++ « natif / MFC ? », leur apporter des dll codées en .net les vont les ennuyer plus qu’autre choses non ?

Finalement comme dis JolyLoic, autant rester pour le cœur du programme en C++, non ?

Quels sont vos avis?

[DeusXL]

JolyLoic => Par "ridicules" j'entendais des critiques venant de personnes qui ne connaissent même pas la chose. Je ne prétends pas que .NET est parfait et moi-même j'apprécie avoir recourt à du code C++ bien souvent mais j'ai exagéré l'adjectif pour insister sur le fait que le manque de réussite du C++/CLI vient aussi d'une certaine incompréhension.
Par contre certaines de tes critiques visent Visual Studio plus que .NET (designer lourd...) ! Mais bon on sort du débat là

radiant => Je pense que personne ne pourra t'apporter une réponse performative. J'aurais tendance à te conseiller d'utiliser le C++/CLI dans ton cas précis parce que c'est dans cette situation que je l'ai utilisé mais c'est assez personnel et d'autres te conseilleront d'utiliser le C++ natif, c'est limite plus une affaire de goût là.

Comment faire du C++ facile à maintenir, simple à lire et à comprendre ?

C'est vrais, mise a part peut être QT, je ne connais pas de framework complet permettant de réaliser facilement thread, communication rs232, impression, etc...

C'est à peu près pour ce genre de raisons que j'ai changé sur .NET à la base (avant de découvrir un réel intérêt dedans). J'avais conscience que c'était un peu naïf mais c'est ainsi. Cette impression m'est partie récemment quand j'ai recommencé le C++ sous Linux et je me suis réconcilié avec (coïncidence ? j'en sais rien)

[JolyLoic]

Par contre certaines de tes critiques visent Visual Studio plus que .NET (designer lourd...) !

Vi, je sais et en suis conscient. C'est d'ailleur pour ça que parmis les avantages, j'en ai aussi cité un lié à Visual studio (la qualité de l'éditeur).

[JolyLoic]

Alors maintenant, que faire…?

Voilà quelques éléments qui n'engagent que moi, sur un choix entre C++ et .NET :

- Si l'équipe possède déjà un bon niveau en C++ et utilise déjà un ensemble de bibliothèques qui couvrent ses besoins, je ne vois pas de raisons de changer.

- Si l'on veut de la portabilité, je n'ai pas l'impression que .NET soit encore mature sur ce point.

- Si l'équipe contient une proportion non négligeable de non experts en informatique et C++, la courbe d'apprentissage de .NET semble bien moins abrupte.

- Si l'application a par endroit besoin de gérer manuellement et précisément ce qui se passe (réels besoins de perf, et pas seulement besoins imaginaires), le C++ est probablement plus approprié.

- Si on veut une IHM qui ressemble à une IHM microsoft (genre MS office), .NET me semble plus approprié.

Pour ce qui est du "C++ moderne", je faisais allusion au fait qu'en C++, du moins pour les couches les plus basses d'une application, les développeurs avaient de plus en plus tendance à s'éloigner de la programmation objet pure (la seule supportée par .NET), pour lui préférer la programmation générique, éventuellement mâtinée d'un peu d'orienté objet. Il n'y a qu'à voir boost pour y voir cette tendance (et ses abus...).

[Marc Lussac]

Je tiens à préciser que du point de vue officiel de www.developpez.com il n'est nullement question de dénigrer ou d'oublier C++/CLI.

Il est exact que nous avons commencé à avoir apparaitre d'abord des resssources pour dotnet pour VB.NET et C#, mais les ressources pour C++ CLI sont maintenant aussi désormais disponible, même s'il est exact si ces ressources ne sont pas encore mise suffisement en avant mais cette omission sera corrigée d'ici peu.

F.A.Q C++/CLI

Tutoriels C++/CLI

[mat.M]

C'est vrais, mise a part peut être QT, je ne connais pas de framework complet permettant de réaliser facilement thread, communication rs232, impression, etc...

Ah bon....et la VCL et MFC c'est incomplet alors ?
Avec ces frameworks on peut pas faire ce dont tu parles..?

Je suppose que des sous traitants dans le monde industiels codent en C/C++ « natif / MFC ? », leur apporter des dll codées en .net les vont les ennuyer plus qu’autre choses non ?

Il n'ya pas que MFC...il y a aussi COM ...
Sinon comme tu dis .NET ne risque pas d'apporter grand chose si ce n'est un monstrueux développement supplémentaires donc une charge développeur/heure supplémentaire

Dans le cas contraire, faut il continuer a faire du C++ MFC ou passer en C++/CLI .net ?
Merci d’avance pour vos infos !

Je dirais presque c'est soit l'un soit l'autre ; si tu peux faire tout le projet en C#/.NET alors fais le sinon effectivement C++/CLI.net à mon avis n'apportera rien de vraiment significatif...