Perché sono richiesti CIL e CLR in .NET?

Perché hanno solo bisogno di scrivere un compilatore per C # in CIL - che è la parte difficile. Fare un interprete (o più spesso, compilatore Just-In-Time) per il CIL per piattaforma è relativamente facile rispetto alla scrittura di un compilatore da C # al codice eseguibile (per piattaforma).

Oltre a ciò, il runtime può gestire tutto ciò che viene compilato in CIL. Se vuoi una nuova lingua (come F #) devi solo scrivere un compilatore one per ottenere automaticamente tutto il supporto della piattaforma per le cose supportate da .NET.

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

Per quanto riguarda le prestazioni, è discutibile. Ci sono essenzialmente "pre-compilatori" che prendono il CIL e creano i binari nativi. Altri sostengono che i compilatori just-in-time possono fare ottimizzazioni che i compilatori statici semplicemente non possono fare. Nella mia esperienza, dipende molto da cosa sta facendo la tua applicazione e da quale piattaforma stai usando (soprattutto quanto è buono il JITer su quella piattaforma). Per me è estremamente raro imbattersi 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 la stessa ragione per cui Java lo fa. Microsoft intendeva C # per competere direttamente con Java, e lo fa, sui sistemi operativi che Microsoft ha come target (il suo).

I vantaggi, anche se .NET è supportato solo su piattaforme Windows (o altri sistemi operativi .NET come Mono / Linux), sono simili a Java:

• Managed Memory Runtime - A differenza degli sviluppatori C / C ++ non gestiti, C # / VB.NET non devono preoccuparsi di controllare rigorosamente la durata dell'oggetto. Come Java, il CLR ha un garbage collector che libera automaticamente gli oggetti nell'heap che lasciano l'ambito. Anche se questo può sembrare secondario a 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 diversamente. 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 ha ancora importanza per uno sviluppatore .NET, la quantità di conoscenza specializzata è molto ridotta rispetto a ciò che deve essere conosciuto per creare un programma C / C ++ compatibile per tutti questi SO. Un C # dev ottiene molto di più gratuitamente.
• Supporto per le applicazioni Web - Non ho ancora visto un'applicazione web con script client-server scritta da zero in C ++. Il web server , sicuro, Apache, ISS, tutti in genere corrono 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 è un codice progettato per funzionare in una sandbox; quale sandbox (il plugin ASP.NET per ISS o CLR "desktop") è relativamente poco importante.
• Indipendenza dalla lingua / autonomia - Un compilatore C ++ prende il codice sorgente C ++ e produce 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 un insieme completamente nuovo di librerie di runtime deve essere compilato). Un compilatore C # 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 partenza (e ce ne sono diversi, C #, VB.NET, F # e un host di porte di linguaggio "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. Ciò riduce la quantità di lavoro che deve essere rifatto da zero per ogni nuova lingua o piattaforma supportata da .NET Framework.
• Concentrarsi sul codice "corretto" - Per gli sviluppatori C ++, ci sono molti modi "giusti" per fare qualcosa, a seconda di cosa è 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 è prioritario. 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 in gran parte vi si trasferiva da C), come così come le lezioni pratiche apprese dalle lingue precedenti (incluso Java, e la sua obbedienza quasi fanatica all'Onnipotente Oggetto, quando un buon vecchio puntatore a funzione di stile C ++ farebbe il lavoro molto più in modo pulito e non essere meno oggetti- oriented).

Per ragioni antitrust, MS sta attento a non essere visto "interferire" troppo pesantemente in altre piattaforme importanti come Android, Mac OSX / iOS e Linux; tuttavia, ha effettivamente lo sviluppo di team per tutte e tre queste piattaforme. Esiste una versione sviluppata da Microsoft di Office per OSX, ci sono numerose applicazioni tra cui app di interoperabilità di Office per iOS e Android, Skype (ora un prodotto Microsoft) eseguito su Linux e Microsoft ha anche visto contribuire al kernel di Linux (principalmente in 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 IL. Ad esempio, un assembly .NET compilato per "qualsiasi CPU" può essere eseguito in genere su Win64 come processo a 64 bit e Win32 come processo a 32 bit, senza la necessità di fornire eseguibili diversi.

Inoltre, il CIL consente di archiviare i metadati negli assembly che non è facilmente possibile con le DLL native (è possibile, naturalmente, MS ha fatto prima con i componenti COM, ma questa tecnologia non è mai stata così facile da gestire come .NET componenti). Ciò rende la creazione di componenti software molto più semplice ed è la base di reflection / introspection in tutto .NET. le lingue.