Perché CIL e CLR sono richiesti in .NET?

Ho visto questa bella immagine qui . Ho imparato che tutti i compilatori che supportano il linguaggio .net convertono il codice sorgente in CILformato. Ora Microsoft non inserisce mai .NETper tutto il sistema operativo scrivendo un CLR per tutti i sistemi operativi. Quindi perché mantenere un tale formato di codice intermedio e un CLR per eseguire quel CIL. Non è un mal di testa da affrontare. Perché Microsoft ha scelto di essere così?

EDIT Questa architettura ha un suo prezzo. Ridurrà le prestazioni, no? Java fa questo per mantenere l'indipendenza della piattaforma, per quale motivo .NET lo fa? Perché non mantenere un semplice compilatore come C semplice. In ogni caso sarà anche necessario un compilatore per convertire il codice in CIL se devo aggiungere una nuova lingua, l'unica differenza che farebbe sarebbe la lingua di destinazione. Tat è tutto.

Perché devono solo scrivere un compilatore per C # in CIL, che è la parte difficile. Creare un interprete (o più spesso, compilatore Just-In-Time) per il CIL per piattaforma è relativamente semplice rispetto alla scrittura di un compilatore dal codice eseguibile C # a (per piattaforma).

Oltre a ciò, il runtime può gestire tutto ciò che viene compilato in CIL. Se vuoi un nuovo linguaggio (come F #) devi solo scrivere un compilatore per esso e otterrai automaticamente tutto il supporto della piattaforma per cose che .NET supporta.

Oh, e posso prendere una DLL .NET ed eseguirla su Windows o Linux via Mono senza ricompilazione (supponendo che tutte le mie dipendenze siano soddisfatte).

Per quanto riguarda le prestazioni, è discutibile. Esistono essenzialmente "pre-compilatori" che prendono il CIL e creano binari nativi. Altri sostengono che i compilatori just-in-time possono fare ottimizzazioni che i compilatori statici semplicemente non possono. Nella mia esperienza, dipende molto da cosa sta facendo la tua applicazione e da quale piattaforma la stai eseguendo (principalmente quanto è buono JITer su quella piattaforma). È estremamente raro per me imbattermi in uno scenario in cui .NET non era abbastanza buono .

.NET ha un linguaggio intermedio (CIL / MSIL) e implementazioni specifiche della piattaforma di un runtime indipendente dalla piattaforma (CLR) per lo stesso motivo di Java. Microsoft intendeva che C # competesse direttamente con Java e lo fa sui sistemi operativi che Microsoft ha scelto (di per sé).

I vantaggi, sebbene .NET sia supportato solo su piattaforme Windows (o altri sistemi operativi che hanno un funzionamento simile a .NET come Mono / Linux), sono simili a Java:

• Managed Memory Runtime - A differenza di C / C ++ non gestito, gli sviluppatori C # / VB.NET non devono preoccuparsi di controllare rigorosamente la durata degli oggetti. Come Java, CLR ha un garbage collector che libera automaticamente gli oggetti nell'heap che lasciano l'ambito. Mentre questo può sembrare minore per qualcuno abituato a runtime non gestiti, ha l'estremo vantaggio secondario di scoraggiare la "magia nera" dell'aritmetica del puntatore che è così comune in C / C ++.
• Indipendenza dalla piattaforma: Windows Vista e Windows 7 funzionano in modo diverso da Windows XP. Windows 8 funziona ancora in modo diverso. Le versioni di Windows Mobile incluso Windows 8 Mobile funzionano di nuovo in modo diverso. Hardware diverso, architettura diversa, capacità diverse. Mentre l'ambiente di destinazione è ancora importante per uno sviluppatore .NET, la quantità di conoscenza specializzata è molto ridotta rispetto a ciò che deve essere noto per costruire un programma C / C ++ compatibile per tutti questi sistemi operativi. AC # dev ottiene molto di più gratuitamente.
• Supporto per applicazioni Web - Non ho ancora visto un'applicazione Web rivolta al client, basata su server, scritta da zero in C ++. Il web server , sicuramente, Apache, ISS, in genere funzionano tutti contro un runtime non gestito per motivi di velocità / efficienza. Tuttavia, C ++ non è un linguaggio utilizzato per la creazione di applicazioni Web. C # è (come è Java). È stato progettato da zero per supportare la prossima generazione del paradigma ASP di Microsoft. Questo è il codice progettato per essere eseguito in un sandbox; quale sandbox (il plug-in ASP.NET per ISS o CLR "desktop") è relativamente poco importante.
• Indipendenza dal linguaggio / runtime - Un compilatore C ++ prende il codice sorgente C ++ e produce il codice assembly per un'architettura di processore usando un linguaggio macchina. Per supportare una diversa architettura e / o linguaggio macchina, è necessario scrivere un compilatore completamente nuovo (e compilare un set completamente nuovo di librerie di runtime). Il compilatore AC # prende il codice sorgente C # e produce CIL, che il JITer specifico dell'hardware traduce in codice macchina. Lo stesso JITer può tradurre qualsiasi programma CIL indipendentemente dalla lingua di origine (e ce ne sono diverse; C #, VB.NET, F # e una serie di porte per la lingua "Iron" come IronHaskell, IronRuby, IronLisp, ecc.). Lo stesso compilatore può trasformare una lingua in CIL che può essere eseguita da qualsiasi JITer, indipendentemente dall'hardware.
• Concentrati sul codice "corretto" - Per gli sviluppatori C ++, ci sono molti modi "giusti" per fare qualcosa, a seconda di ciò che è più importante; efficienza della memoria, efficienza della CPU, indipendenza dell'hardware, indipendenza del sistema operativo, ecc. Il codice può apparire drasticamente diverso quando ognuno di questi è la priorità. C # è stato progettato da un gruppo che ha preso a cuore le lezioni concettuali di Fowler e dei suoi colleghi (che stavano lavorando per riformare la progettazione del codice all'interno della comunità C ++ insegnando principi orientati agli oggetti a una comunità che si è trasferita in gran parte da C), come così come le lezioni pratiche apprese dai linguaggi precedenti (incluso Java, e la sua obbedienza quasi fanatica all'Onnipotente Oggetto, quando un buon vecchio puntatore a funzioni in stile C ++ farebbe il lavoro in modo molto più pulito e non sarebbe meno oggetto- orientate).

Per ragioni antitrust, la MS sta attenta a non essere vista "interferire" troppo pesantemente in altre piattaforme importanti come Android, Mac OSX / iOS e Linux; tuttavia, ha davvero team di sviluppo per tutte e tre queste piattaforme. Esiste una versione di Office per OSX sviluppata da MS, ci sono numerose applicazioni tra cui app di interoperabilità di Office per iOS e Android, Skype (ora un prodotto Microsoft) gira su Linux e Microsoft ha persino visto contribuire al kernel Linux (principalmente in un mentalità di virtualizzazione).

Il sistema operativo Windows è disponibile per diversi tipi di CPU, oggi principalmente x64, x86, Intel, ARM.

CIL / CLR è indipendente da quella piattaforma hardware - queste differenze sono "astratte" dall'ambiente di esecuzione di IL. Ad esempio, un assembly .NET compilato per "qualsiasi CPU" può in genere essere eseguito su Win64 come processo a 64 bit e Win32 come processo a 32 bit, senza la necessità di fornire diversi eseguibili.

Inoltre, il CIL consente di archiviare i metadati in assiemi che non è facilmente possibile con le DLL native (è possibile, naturalmente, MS lo ha fatto prima con i componenti COM, ma quella tecnologia non è mai stata così facile da gestire come i componenti .NET). Ciò rende la creazione di componenti software molto più semplice ed è il fondamento della riflessione / introspezione in tutti i linguaggi .NET.