Pourquoi CIL et CLR sont-ils requis dans .NET?

J'ai vu cette belle image ici . J'ai appris que tous les compilateurs qui prennent en charge le langage .net convertissent le code source au CILformat. Désormais, Microsoft n'intègre jamais .NETtout le système d'exploitation en écrivant un CLR pour tous les systèmes d'exploitation. Alors pourquoi garder un tel format de code intermédiaire et un CLR pour exécuter ce CIL. N'est-ce pas un casse-tête à gérer. Pourquoi Microsoft a-t-il choisi d'être comme ça?

EDIT Cette architecture a un prix. Cela réduira les performances, non? Java le fait pour maintenir l'indépendance de la plate-forme, pour quelle raison .NET le fait-il? Pourquoi ne pas garder un simple compilateur en C simple. De toute façon, il faudra également un compilateur pour convertir le code en CIL si j'ai besoin d'ajouter une nouvelle langue, la seule différence que cela ferait est la langue cible. Tat est tout.

Parce qu'ils n'ont besoin d'écrire qu'un seul compilateur pour C # vers CIL - ce qui est la partie difficile. Faire un interprète (ou plus souvent, un compilateur Just-In-Time) pour le CIL par plate-forme est relativement facile par rapport à l'écriture d'un compilateur de C # en (par plate-forme) de code exécutable.

Au-delà, le runtime peut gérer tout ce qui se compile en CIL. Si vous voulez un nouveau langage (comme F #), vous n'avez qu'à écrire un compilateur pour celui-ci et vous obtenez automatiquement tout le support de la plate-forme pour les choses que .NET prend en charge.

Oh, et je peux prendre une DLL .NET et l'exécuter sur Windows ou sur Linux via Mono sans recompilation (en supposant que toutes mes dépendances sont satisfaites).

Quant aux performances, c'est discutable. Il existe essentiellement des "pré-compilateurs" qui prennent le CIL et font des binaires natifs. D'autres soutiennent que les compilateurs juste à temps peuvent faire des optimisations que les compilateurs statiques ne peuvent tout simplement pas. D'après mon expérience, cela dépend beaucoup de ce que fait votre application et de la plate-forme sur laquelle vous l'exécutez (principalement la qualité du JITer sur cette plate-forme). Il est extrêmement rare pour moi de rencontrer un scénario où .NET n'était pas assez bon .

.NET possède un langage intermédiaire (CIL / MSIL) et des implémentations spécifiques à la plate-forme d'un runtime indépendant de la plate-forme (CLR) pour la même raison que Java. Microsoft avait l'intention que C # soit en concurrence directe avec Java, et il le fait, sur les systèmes d'exploitation que Microsoft cible (le sien).

Les avantages, même si .NET n'est pris en charge que sur les plates-formes Windows (ou d'autres systèmes d'exploitation qui ont un travail similaire à .NET comme Mono / Linux), sont similaires à Java:

• Durée d'exécution de la mémoire gérée - Contrairement à C / C ++ non managé, les développeurs C # / VB.NET n'ont pas à se soucier de contrôler strictement la durée de vie des objets. Comme Java, le CLR possède un garbage collector qui libère automatiquement les objets du tas qui quittent la portée. Bien que cela puisse sembler mineur à quelqu'un habitué aux temps d'exécution non gérés, cela a l'avantage secondaire extrême de décourager la «magie noire» de l'arithmétique des pointeurs qui est si courante en C / C ++.
• Indépendance de la plate-forme - Windows Vista et Windows 7 fonctionnent différemment de Windows XP. Windows 8 fonctionne toujours différemment. Les versions de Windows Mobile, y compris Windows 8 Mobile, fonctionnent à nouveau différemment. Matériel différent, architecture différente, capacités différentes. Bien que l'environnement cible ait toujours de l'importance pour un développeur .NET, la quantité de connaissances spécialisées est de loin réduite par rapport à ce qui doit être connu pour construire un programme C / C ++ compatible pour tous ces systèmes d'exploitation. AC # dev obtient beaucoup plus gratuitement.
• Prise en charge des applications Web - Je n'ai pas encore vu une application Web client-scriptée par le serveur écrite à partir de zéro en C ++. Le serveur Web , bien sûr, Apache, ISS, ils s'exécutent généralement sur un environnement d'exécution non géré pour des raisons de vitesse / efficacité. Cependant, C ++ n'est pas un langage utilisé pour créer des applications Web. C # est (tout comme Java). Il a été conçu dès le départ pour prendre en charge la prochaine génération du paradigme ASP de Microsoft. Il s'agit d'un code conçu pour s'exécuter dans un bac à sable; quel bac à sable (le plugin ASP.NET pour ISS ou le CLR "de bureau") est relativement sans importance.
• Indépendance vis-à-vis du langage / de l'exécution - Un compilateur C ++ prend le code source C ++ et produit le code assembleur pour une architecture de processeur en utilisant un langage machine. Pour prendre en charge une architecture et / ou un langage machine différents, un tout nouveau compilateur doit être écrit (et un tout nouvel ensemble de bibliothèques d'exécution doit être compilé). Le compilateur AC # prend le code source C # et produit CIL, que le JITer spécifique au matériel traduit en code machine. Le même JITer peut traduire n'importe quel programme CIL, quelle que soit la langue source (et il y en a plusieurs; C #, VB.NET, F # et une multitude de ports de langage "Iron" comme IronHaskell, IronRuby, IronLisp, etc.). Le même compilateur peut transformer une langue en CIL que n'importe quel JITer peut exécuter, quel que soit le matériel.
• Concentrez-vous sur le code «correct» - Pour les développeurs C ++, il existe de nombreuses «bonnes» façons de faire quelque chose, selon ce qui est le plus important; efficacité de la mémoire, efficacité du processeur, indépendance du matériel, indépendance du système d'exploitation, etc. Le code peut être radicalement différent lorsque chacun d'eux est la priorité. C # a été conçu par un groupe qui a pris à cœur les leçons conceptuelles de Fowler et de ses collègues (qui travaillaient à réformer la conception de code au sein de la communauté C ++ en enseignant des principes orientés objet à une communauté qui y est largement passée de C), comme ainsi que les leçons pratiques tirées des langages précédents (y compris Java et son obéissance quasi fanatique à l'Objet tout-puissant, quand un bon vieux pointeur de fonction de style C ++ ferait le travail beaucoup plus proprement et ne serait pas moins objet) orienté).

Pour des raisons antitrust, MS fait attention à ne pas être vu "interférer" trop fortement dans d'autres plates-formes majeures comme Android, Mac OSX / iOS et Linux; cependant, il dispose en effet d'équipes développant pour ces trois plates-formes. Il existe une version développée par MS pour Office pour OSX, il existe de nombreuses applications, y compris les applications Office Interop pour iOS et Android, Skype (maintenant un produit Microsoft) fonctionne sur Linux, et Microsoft a même été vu contribuer au noyau Linux (principalement dans un état d'esprit de virtualisation).

Le système d'exploitation Windows est disponible pour différents types de CPU, aujourd'hui principalement x64, x86, Intel, ARM.

CIL / CLR est indépendant de cette plate-forme matérielle - ces différences sont "résumées" par l'environnement d'exécution IL. Par exemple, un assemblage .NET compilé pour "n'importe quel CPU" peut généralement être exécuté sur Win64 en tant que processus 64 bits et Win32 en tant que processus 32 bits, sans avoir besoin de fournir différents exécutables.

De plus, le CIL permet de stocker des métadonnées dans des assemblages, ce qui n'est pas facilement possible avec des DLL natives (il est possible, bien sûr, que MS ait fait cela auparavant avec des composants COM, mais cette technologie n'a jamais été aussi facile à gérer que les composants .NET). Cela rend la création de composants logiciels beaucoup plus simple et constitue le fondement de la réflexion / introspection dans tous les langages .NET.