C ++ / CLI: pourquoi devrais-je l'utiliser?
Je suis assez familier avec C++, j'ai donc envisagé d'apprendre .NET et tous ses dérivés (en particulier C #).
En chemin, je suis tombé sur C++/CLI, et je veux savoir s'il y a une utilisation spécifique pour ce langage? Est-ce simplement supposé être un langage intermédiaire pour passer du C++ natif au C #?
Une autre question qui m'est venue à l'esprit est la suivante: pourquoi y a-t-il encore autant de langages de programmation dans le framework .NET? (VB, C++/CLI, C # ...)
Oui, C++/CLI a une utilisation cible très spécifique, le langage (et son compilateur, surtout) facilite l'écriture de code qui doit interagir avec du code non managé. Il a un support intégré pour le marshaling entre les types managés et non managés. Il s'appelait auparavant IJW (It Just Works), aujourd'hui appelé C++ Interop. D'autres langages doivent utiliser le marshaller P/Invoke qui peut être inefficace et a des capacités limitées par rapport à ce que C++/CLI peut faire.
Si vous devez interagir avec du C++ natif, des classes qui ont des fonctions d'instance et qui ont besoin des mots-clés new et delete pour créer/détruire une instance de la classe, vous n'avez pas d'autre choix que d'utiliser C++/CLI. Pinvoke ne peut pas faire cela, seul le compilateur C++ sait combien de mémoire allouer et comment correctement thunk le pointeur this pour une fonction d'instance.
Le framework .NET contient du code écrit en C++/CLI, notamment dans System.Data et WPF's PresentationCore. Si vous n'avez pas besoin d'interopérabilité non gérée ou n'avez pas à travailler avec une base de code héritée, il y a peu de raisons de sélectionner C++/CLI. C # ou VB.NET sont les meilleurs choix. L'ensemble de fonctionnalités de C++/CLI a été gelé vers 2005, il ne prend pas en charge les ajouts plus récents tels que lambdas ou la syntaxe Linq. Le IDE ne prend pas en charge la plupart des cloches et des sifflets disponibles dans les IDE C # et VB.NET. Il est à noter que VS2010 sera initialement livré sans le support IntelliSense pour C++/CLI. Un petit baiser -de-la mort là-bas.
MISE À JOUR: relancé dans VS2012, le support IntelliSense est de retour. Pas du tout grâce à C++/CX, une extension de langage qui simplifie l'écriture d'applications WinRT en C++. Sa syntaxe est très similaire à C++/CLI. Les modèles de projet Windows Forms ont été supprimés, le concepteur fonctionne cependant toujours. Le nouveau moteur de débogage dans VS2012 ne prend pas en charge C++/CLI, vous devez activer l'option "Mode de compatibilité géré" dans Outils + Options, Débogage, Général.
Tout d'abord, C # n'est pas un "dérivé" de .NET. .NET n'est pas un langage, c'est un cadre d'application et une bibliothèque de classes basés sur le CLR, pour lesquels un certain nombre de langages existent.
Cela dit, la raison la plus convaincante d'utiliser .NET est qu'il s'agit d'une bibliothèque de classes bien conçue et d'un moyen beaucoup plus facile de développer pour Windows que Win32 ou MFC. Cependant, j'ai personnellement décidé que je préfèrerais apprendre un nouveau langage plutôt que d'apprendre des extensions à un ancien, et parce que C # a été conçu dès le départ pour fonctionner avec .NET, je suggère que c'est le langage de choix pour .NET.
C++/CLI est utile si vous souhaitez utiliser .NET avec du code hérité, et je l'ai utilisé pour créer des interfaces graphiques Windows Forms et les coller au code d'application existant. Son autre raison d'être est qu'il s'agit du seul langage .NET qui prend en charge le code mixte géré et natif dans un module de chargement unique, il est donc bon pour les performances et la réutilisation du code hérité.
En ce qui concerne le nombre de langues, Microsoft souhaite que chaque application Windows soit basée sur .NET car elle est meilleure pour la sécurité et la stabilité de leur système d'exploitation. La seule façon de le faire est de prendre en charge plusieurs langues. Considérez .NET comme une plate-forme d'application ou une API de système d'exploitation, puis la question est moins logique; il y aura de nombreuses langues pour .NET pour la même raison qu'il existe de nombreuses langues pour n'importe quelle plate-forme. Ces raisons sont nombreuses, notamment l'avantage commercial, l'adéquation de l'application, la politique, le soutien aux développeurs existants, le choix et sans aucun doute plus.
Microsoft a changé sa position à ce sujet à plusieurs reprises. C'était à l'origine conçu comme un langage à part entière, essentiellement quelque chose qu'ils voulaient que tous les développeurs natifs migrent vers, abandonnant autant que possible le C++ natif.
Il y a quelques années, ils ont réalisé que ce n'était tout simplement pas ce que leurs clients voulaient. Les développeurs qui migrent vers .NET de toute façon passent généralement à un langage comme C #, et les autres ont des raisons de garder leur code dans le monde natif, ils restent donc avec C++.
Alors maintenant, Microsoft entend que C++/CLI soit un "pont" entre le code C++ natif et le code managé écrit dans un langage .NET. Ce n'est plus une langue dans laquelle ils vous recommandent de basculer l'intégralité de votre base de code.
Il est en effet principalement conçu comme un langage intermédiaire pour lier facilement le code .net avec du C++ natif non géré. Faites-vous plaisir, ne l'utilisez pas si vous n'en avez pas besoin. La syntaxe C++/CLI est un gâchis.
Concernant votre deuxième question ... Je pense qu'aujourd'hui C # est le langage dominant en .net, mais tout le monde n'aime pas son style et ses paradigmes. L'architecture de .net facilite l'ajout de nouveaux langages (voir F #, qui vise la programmation fonctionnelle).
J'ai utilisé C++/CLI pour créer des API .NET pour certaines bibliothèques C++ non gérées. Passer et rassembler des paramètres prend un certain temps pour s'y habituer (selon les types utilisés), mais une fois que vous avez compris, c'est vraiment une belle façon de combler l'écart entre le monde géré et non géré.
Je n'ai pas regardé C++/CLI mais il exploite le monde .NET - pensez-y comme un entre C++ et C # où vous avez le meilleur des deux mondes. Cela pourrait être utile dans les situations où vous souhaitez utiliser C++ qui peut facilement accéder aux objets .NET et à son noyau BCL. Jetez un oeil ici à cette article discutant les amorces de C++/CLI. Malheureusement, je n'ai pas entendu parler d'une application Managed C++ car elle a ébouriffé beaucoup d'amis C++ du côté de la syntaxe et perdu le rassemblement d'adeptes qui sont retournés dans le monde non managé de C++.
J'espère que cela vous aide, Cordialement, Tom.
pour moi, je dois l'utiliser quand il n'y a pas d'autre moyen de réutiliser la classe c ++