Warum sind CIL und CLR in .NET erforderlich?

Ich habe dieses schöne Bild hier gesehen . Ich habe erfahren, dass alle Compiler, die die .net-Sprache unterstützen, den Quellcode in das CILFormat konvertieren. Jetzt bringt Microsoft niemals das .NETgesamte Betriebssystem ein, indem es eine CLR für alle Betriebssysteme schreibt. Warum sollten Sie dann ein solches Zwischencodeformat und eine CLR beibehalten, um diese CIL auszuführen? Ist das nicht Kopfschmerzen zu behandeln. Warum hat Microsoft so gewählt?

BEARBEITEN Diese Art von Architektur hat ihren Preis. Es wird die Leistung reduzieren, nicht wahr? Java tut dies, um die Plattformunabhängigkeit aufrechtzuerhalten. Aus welchem ​​Grund tut .NET dies? Warum nicht einen einfachen C-ähnlichen Compiler behalten? In jedem Fall muss ein Compiler den Code in CIL konvertieren, wenn ich eine neue Sprache hinzufügen muss. Der einzige Unterschied wäre die Zielsprache. Tat ist alles.

Weil sie nur einen Compiler für C # in CIL schreiben müssen - was der schwierige Teil ist. Das Erstellen eines Interpreters (oder häufiger eines Just-In-Time-Compilers) für die CIL pro Plattform ist relativ einfach im Vergleich zum Schreiben eines Compilers von C # in (pro Plattform) ausführbaren Code.

Darüber hinaus kann die Laufzeit alles verarbeiten, was zu CIL kompiliert wird. Wenn Sie eine neue Sprache (wie F #) möchten, müssen Sie nur einen Compiler dafür schreiben , und Sie erhalten automatisch die gesamte Plattformunterstützung für Dinge, die .NET unterstützt.

Oh, und ich kann eine .NET-DLL nehmen und diese unter Windows oder Linux über Mono ohne Neukompilierung ausführen (vorausgesetzt, alle meine Abhängigkeiten sind erfüllt).

Die Leistung ist umstritten. Es gibt im Wesentlichen "Pre-Compiler", die die CIL verwenden und native Binärdateien erstellen. Andere argumentieren, dass Just-in-Time-Compiler Optimierungen vornehmen können, die statische Compiler einfach nicht können. Nach meiner Erfahrung hängt es stark davon ab, was Ihre Anwendung tut und auf welcher Plattform Sie sie ausführen (hauptsächlich, wie gut der JITer auf dieser Plattform ist). Es ist äußerst selten, dass ich auf ein Szenario stoße, in dem .NET nicht gut genug war .

.NET verfügt aus dem gleichen Grund wie Java über eine Zwischensprache (CIL / MSIL) und plattformspezifische Implementierungen einer plattformunabhängigen Laufzeit (CLR). Microsoft beabsichtigte, C # direkt mit Java zu konkurrieren, und zwar auf den Betriebssystemen, auf die Microsoft abzielt (seine eigenen).

Die Vorteile sind ähnlich wie bei Java, obwohl .NET nur auf Windows-Plattformen (oder anderen Betriebssystemen mit .NET-ähnlichen Funktionen wie Mono / Linux) unterstützt wird:

• Managed Memory Runtime - Im Gegensatz zu nicht verwaltetem C / C ++ müssen sich C # / VB.NET-Entwickler nicht um die strikte Kontrolle der Objektlebensdauer kümmern. Wie Java verfügt auch die CLR über einen Garbage Collector, der automatisch Objekte im Heap freigibt, die den Gültigkeitsbereich verlassen. Während dies für jemanden, der an nicht verwaltete Laufzeiten gewöhnt ist, unbedeutend erscheint, hat es den äußersten sekundären Vorteil, die in C / C ++ so übliche "schwarze Magie" der Zeigerarithmetik zu entmutigen.
• Plattformunabhängigkeit - Windows Vista und Windows 7 funktionieren anders als Windows XP. Windows 8 funktioniert immer noch anders. Windows Mobile-Versionen einschließlich Windows 8 Mobile funktionieren wieder anders. Unterschiedliche Hardware, unterschiedliche Architektur, unterschiedliche Funktionen. Während die Zielumgebung für einen .NET-Entwickler immer noch von Bedeutung ist, ist der Umfang des Fachwissens im Vergleich zu dem, was bekannt sein muss, um ein kompatibles C / C ++ - Programm für alle diese Betriebssysteme zu erstellen, erheblich reduziert. AC # dev bekommt viel mehr kostenlos.
• Unterstützung von Webanwendungen - Ich habe noch keine Client-bezogene Webanwendung mit Serverskript gesehen, die von Grund auf in C ++ geschrieben wurde. Der Web - Server , sicher, Apache, ISS, sie alle in der Regel laufen gegen eine nicht verwaltete Laufzeit für Geschwindigkeit / Effizienzgründen. C ++ ist jedoch keine Sprache zum Erstellen von Webanwendungen. C # ist (wie auch Java). Es wurde von Grund auf entwickelt, um die nächste Generation des ASP-Paradigmas von Microsoft zu unterstützen. Dies ist Code, der für die Ausführung in einer Sandbox entwickelt wurde. Welche Sandbox (das ASP.NET-Plugin für ISS oder die "Desktop" -CLR) ist relativ unwichtig.
• Sprach- / Laufzeitunabhängigkeit - Ein C ++ - Compiler verwendet C ++ - Quellcode und erstellt Assembler-Code für eine Prozessorarchitektur unter Verwendung einer Maschinensprache. Um eine andere Architektur und / oder Maschinensprache zu unterstützen, muss ein völlig neuer Compiler geschrieben werden (und ein völlig neuer Satz von Laufzeitbibliotheken muss kompiliert werden). Der AC # -Compiler verwendet C # -Quellcode und erzeugt CIL, das der hardwarespezifische JITer in Maschinencode übersetzt. Der gleiche JITer kann jedes CIL-Programm unabhängig von der Ausgangssprache übersetzen (und es gibt mehrere; C #, VB.NET, F # und eine Vielzahl von "Iron" -Sprachenports wie IronHaskell, IronRuby, IronLisp usw.). Der gleiche Compiler kann eine Sprache in CIL umwandeln, die jeder JITer ausführen kann, unabhängig von der Hardware.
• Konzentrieren Sie sich auf "richtigen" Code - Für C ++ - Entwickler gibt es viele "richtige" Möglichkeiten, etwas zu tun, je nachdem, was am wichtigsten ist. Speichereffizienz, CPU-Effizienz, Hardwareunabhängigkeit, Betriebssystemunabhängigkeit usw. Code kann drastisch anders aussehen, wenn jede dieser Prioritäten Priorität hat. C # wurde von einer Gruppe entworfen, die sich die konzeptionellen Lehren von Fowler und seinen Kollegen zu Herzen nahm (die daran arbeiteten, das Code-Design innerhalb der C ++ - Community zu reformieren, indem sie einer Community objektorientierte Prinzipien beibrachten, die sich weitgehend von C nach oben bewegte) sowie die praktischen Lektionen, die die vorhergehenden Sprachen gelernt haben (einschließlich Java und sein fast fanatischer Gehorsam gegenüber dem allmächtigen Objekt, wenn ein guter alter Funktionszeiger im C ++ - Stil die Arbeit viel sauberer erledigen und nicht weniger objektiv sein würde). orientiert).

Aus kartellrechtlichen Gründen achtet MS darauf, dass andere wichtige Plattformen wie Android, Mac OSX / iOS und Linux nicht zu stark "gestört" werden. Es gibt jedoch tatsächlich Teams, die sich für alle drei dieser Plattformen entwickeln. Es gibt eine von MS entwickelte Version von Office für OSX, es gibt zahlreiche Anwendungen, einschließlich Office Interop-Apps für iOS und Android, Skype (jetzt ein Microsoft-Produkt) läuft unter Linux, und Microsoft hat sogar einen Beitrag zum Linux-Kernel geleistet (hauptsächlich in a Virtualisierungs-Denkweise).

Das Windows-Betriebssystem ist für verschiedene CPU-Typen verfügbar, heute hauptsächlich x64, x86, Intel, ARM.

CIL / CLR ist unabhängig von dieser Hardwareplattform - diese Unterschiede werden von der IL-Ausführungsumgebung "abstrahiert". Beispielsweise kann eine für "jede CPU" kompilierte .NET-Assembly normalerweise unter Win64 als 64-Bit-Prozess und unter Win32 als 32-Bit-Prozess ausgeführt werden, ohne dass unterschiedliche ausführbare Dateien bereitgestellt werden müssen.

Darüber hinaus ermöglicht die CIL das Speichern von Metadaten in Assemblys, was mit nativen DLLs nicht einfach möglich ist (es ist natürlich möglich, dass MS dies zuvor mit COM-Komponenten getan hat, aber diese Technologie war nie so einfach zu handhaben wie .NET-Komponenten). Das macht die Erstellung von Softwarekomponenten um einiges einfacher und ist die Grundlage für Reflexion / Selbstbeobachtung in allen .NET-Sprachen.