Y a-t-il un avantage majeur de géré C ++ / CLI sur C #. Ce n'est certainement pas la syntaxe que je suppose que le code suivant en C ++ / CLI est un véritable code laids,
C ++ / CLI code: P> comparer ci-dessus avec C # Code: P > out List<SomeObject> someVariable
11 Réponses :
L'avantage de géré C ++ est qu'il est facile de mélanger du code géré et non géré. Mais si tout (ou presque tout) de votre code sera géré, alors c # devrait certainement être utilisé (et vous pouvez toujours
Une interopération plus facile avec le code Native C ++ est l'avantage.
Que ce soit un avantage majeur est subjectif.
Sauf si vous voulez me mêler au code Native C ++ existant, vous êtes probablement beaucoup mieux avec C #.
Bonne réponse. Mais ce n'est pas vraiment subjectif - c'est un avantage majeur si (et seulement si) vous n'avez d'autre choix que de traiter le code natif existant.
C'est toujours subjectif. Si ce dont vous avez besoin est d'utiliser une DLL existante, vous pouvez choisir d'interagir avec le code existant à l'aide de C # et d'utiliser p / invoke. Que ce soit un avantage "majeur" ou un avantage "mineur" pour que vous puissiez plus facile Interop contre un avantage "majeur" ou un avantage "mineur" d'avoir C # est totalement à la hauteur de la question.
Utilisation C ++ / CLI Il est très facile d'interagir avec le code Native C ++
Vous venez de vous tourner vers C ++ \ CLI lorsque vous devez, si vous pouvez vous répondre à votre exigence à l'aide de C #, pourquoi go c ++ \ cli
Généralement, je pense que l'avantage principal de C ++ / CLI est tout simplement familiarité pour les développeurs C ++. Si vous ne venez pas d'un arrière-plan C ++, passez avec C #.
Je pense que ce n'est pas le cas. Je viens d'un fond C ++ (mélangé avec Java et Delphi) et C # était si simple à saisir. Pas besoin de C ++ / CLI Juste pour la familiarité. J'étais plutôt chanceux de vous échapper de la syntaxe C ++ :)
Intéressant, cela fait longtemps que je faisais un C ++ mais j'ai supposé que la syntaxe C ++ / CLI serait plus familière que c #, mais je ne suppose pas!
C'est presque exclusivement une langue d'interopasibilité - à la fois pour permettre au code .NET d'accéder aux bibliothèques héracy c ++ ou pour les bases de code C ++ existantes existantes (natif) avec accès aux bibliothèques .NET (et à certaines variations de ces thèmes).
tandis que est est possible d'écrire des applications entièrement éclairées uniquement dans C ++ / CLI, et il vous donne même certaines fonctionnalités de langue non disponibles dans Pure C ++ (telle que la collecte des ordures), je doute qu'il y ait beaucoup les gens qui feraient cela. Si vous quittez déjà Pure C ++ et que vous n'avez pas l'objectif d'Interop avec .NET, il y a probablement plus de choix naturels (tels que D ou Scala , par exemple - en fonction de la direction souhaitée entrer).
De même, passer de Pure C # à C ++ / CLI pourrait subir des avantages des modèles C ++, mais il est rare que ce besoin vous conduirait à prendre cette étape.
Je peux ajouter pour soutenir cela. Dans un projet précédent, je devais écrire une interface entre une application de service Web ASMX C # ASMX et IBM Middleware qui n'avait qu'une bibliothèque API C ++ (pas une DLL, mais une LIB statique). C ++ / CLI était le seul choix de créer ce pont.
Une implémentation d .NET est dans les travaux. C'est peut-être que, dans un avenir proche, D peut interagir avec .NET.
Je peux penser à 3 raisons principales d'utiliser C ++ / CLI:
Pourriez-vous élaborer le point 3 en ce qui concerne la reconnaissance vocale ou le traitement de l'image?
Traitement des images en C ++ => Boost.org/doc/ LIBS / 1_41_0 / LIBS / GIL / DOC / INDEX.HTML
Les applications C ++ non gérées n'ont pas besoin d'un cadre à exécuter, C # ne s'exécutera que sur des machines avec DotNet Framework 1, 2, 3 ou 4. Il surprenant combien de machines fonctionnent toujours sans ces cadres.
Etre un programmeur principal C #, je me trouvais à avoir à utiliser C ++ / CLI avec un peu de douleur. Cependant, comme une langue interopère, il dépasse de loin C # pour avoir à travailler avec un code natif. L'IDE C ++ / CLI dans Visual Studio manque de nombreuses caractéristiques de la saveur C #.
Globalement, il a sa place et restera viable tant que le code natif existe. Je ne voudrais pas avoir à créer des applications WinForm à partir de zéro avec l'IDE C ++ / CLI si je n'avais pas à.
Être capable d'utiliser des fichiers d'en-têtes natifs directement est un avantage énorme, mais pas le seul.
Stack Semantitique est tellement meilleur que tout ce que c # a à offrir pour vs maintenant quelle langue a l'air laide? alors il y a Modèles, Idisposable Gestion. C ++ / CLI a une syntaxe uniforme pour gérer correctement les variables Idisposables et ceux qui ne sont pas, à la fois en tant que variables locales et en tant que champs membres. Comparaison: INTERIAL_PTR , #DEFINE , DLL natif des exportations, pointer-to-member et probablement plusieurs autres choses que j'ai oubliées.
Je suis d'accord, sauf #define. De mon point de vue, son utilisation immense et indifférente dans de nombreux projets est un pita.
CLI / C ++ présente de nombreux avantages sur C #.
Je déteste avoir à faire confiance à GC pour accéder à un objet coincé sur le Gen 2. Seigneur sait quand cela sera libéré du tas géré.