Dlaczego w .NET wymagane są CIL i CLR?

Widziałem tutaj ten ładny obraz . Dowiedziałem się, że wszystkie kompilatory obsługujące język .net konwertują kod źródłowy na CILformat. Teraz Microsoft nigdy nie wprowadza .NETcałego systemu operacyjnego, pisząc CLR dla wszystkich systemów operacyjnych. Dlaczego więc zachować taki pośredni format kodu i CLR, aby wykonać ten CIL. Czy to nie ból głowy? Dlaczego Microsoft tak wybrał?

EDYCJA Ten rodzaj architektury ma swoją cenę. Zmniejszy to wydajność, prawda? Java robi to, aby zachować niezależność platformy, z jakiego powodu .NET to robi? Dlaczego nie zachować prostego kompilatora typu C? Jakikolwiek sposób będzie wymagał również kompilatora do konwersji kodu na CIL, jeśli będę musiał dodać nowy język, jedyną różnicą, jaką by to zrobił, był język docelowy. Tat jest wszystkim.

Ponieważ muszą napisać tylko jeden kompilator dla C # do CIL - co jest trudną częścią. Utworzenie interpretera (lub częściej kompilatora Just-In-Time) dla CIL na platformę jest stosunkowo łatwe w porównaniu z pisaniem kompilatora z kodu C # na (na platformę) kod wykonywalny.

Poza tym środowisko wykonawcze może obsłużyć wszystko, co kompiluje się do CIL. Jeśli chcesz nowego języka (np. F #), musisz napisać dla niego tylko jeden kompilator i automatycznie uzyskać wsparcie platformy dla rzeczy obsługiwanych przez platformę .NET.

Aha, mogę pobrać bibliotekę .NET i uruchomić ją w systemie Windows lub Linux na Mono bez ponownej kompilacji (zakładając, że wszystkie moje zależności są spełnione).

Jeśli chodzi o wydajność, jest to dyskusyjne. Istnieją „prekompilatory”, które zasadniczo pobierają CIL i tworzą natywne pliki binarne. Inni twierdzą, że kompilatory just-in-time mogą dokonywać optymalizacji, których po prostu nie potrafią kompilatory statyczne. Z mojego doświadczenia wynika, że ​​wiele zależy od tego, co robi twoja aplikacja i na jakiej platformie ją uruchamiasz (głównie jak dobry jest JITer na tej platformie). Bardzo rzadko spotykam się ze scenariuszem, w którym .NET nie był wystarczająco dobry .

.NET ma język pośredni (CIL / MSIL) i specyficzne dla platformy implementacje niezależnego od platformy środowiska uruchomieniowego (CLR) z tego samego powodu, dla którego robi to Java. Microsoft zamierzał C # bezpośrednio konkurować z Javą, i robi to w systemach operacyjnych, na które Microsoft celuje (swoim własnym).

Korzyści, mimo że .NET jest obsługiwany tylko na platformach Windows (lub innych systemach operacyjnych, które działają podobnie do .NET, jak Mono / Linux), są podobne do Java:

• Środowisko wykonawcze pamięci zarządzanej - w przeciwieństwie do niezarządzanego C / C ++, programiści C # / VB.NET nie muszą martwić się o ścisłą kontrolę czasu życia obiektu. Podobnie jak Java, CLR ma moduł wyrzucający elementy bezużyteczne, który automatycznie uwalnia obiekty na stercie, które opuszczają zakres. Chociaż może się to wydawać mało istotne dla kogoś przyzwyczajonego do niezarządzanych środowisk uruchomieniowych, ma on tę drugą nadzwyczajną zaletę, że zniechęca do „czarnej magii” arytmetyki wskaźników, tak powszechnej w C / C ++.
• Niezależność od platformy - Windows Vista i Windows 7 działają inaczej niż Windows XP. Windows 8 działa nadal inaczej. Wersje Windows Mobile, w tym Windows 8 Mobile, znów działają inaczej. Inny sprzęt, inna architektura, różne możliwości. Chociaż środowisko docelowe wciąż ma znaczenie dla programisty .NET, ilość specjalistycznej wiedzy jest znacznie zmniejszona w porównaniu z tym, co trzeba wiedzieć, aby zbudować kompatybilny program C / C ++ dla wszystkich tych systemów operacyjnych. AC # dev dostaje o wiele więcej za darmo.
• Obsługa aplikacji internetowych - jeszcze nie widziałem aplikacji internetowej skierowanej do klienta, napisanej od podstaw w C ++. W internecie serwer , na pewno, Apache, ISS, wszystkie one zwykle uruchamiane przeciwko niekontrolowana starcie z przyczyn prędkości / wydajności. Jednak C ++ nie jest językiem używanym do tworzenia aplikacji internetowych. C # to (podobnie jak Java). Został zaprojektowany od podstaw, aby wspierać następną generację paradygmatu ASP Microsoft. Jest to kod zaprojektowany do działania w piaskownicy; który piaskownica (wtyczka ASP.NET do ISS lub CLR „desktop”) jest stosunkowo nieistotna.
• Niezależność od języka / środowiska wykonawczego - kompilator C ++ pobiera kod źródłowy C ++ i tworzy kod zestawu dla architektury jednego procesora przy użyciu jednego języka maszynowego. Aby obsługiwać inną architekturę i / lub język maszynowy, należy napisać zupełnie nowy kompilator (i skompilować całkowicie nowy zestaw bibliotek wykonawczych). Kompilator AC # pobiera kod źródłowy C # i generuje plik CIL, który specyficzny dla sprzętu JITer tłumaczy na kod maszynowy. Ten sam JITer może tłumaczyć dowolny program CIL bez względu na język źródłowy (a jest ich kilka; C #, VB.NET, F # i wiele portów języka „Iron”, takich jak IronHaskell, IronRuby, IronLisp itp.). Ten sam kompilator może przekształcić jeden język w język CIL, który może działać dowolny JITer, bez względu na sprzęt.
• Skoncentruj się na „poprawnym” kodzie - dla programistów C ++ istnieje wiele „właściwych” sposobów na zrobienie czegoś, w zależności od tego, co najważniejsze; wydajność pamięci, wydajność procesora, niezależność sprzętowa, niezależność systemu operacyjnego itp. Kod może wyglądać drastycznie inaczej, gdy każdy z nich jest priorytetem. C # został zaprojektowany przez grupę, która wzięła sobie do serca lekcje pojęciowe Fowlera i jego współpracowników (którzy pracowali nad reformą projektowania kodu w społeczności C ++, ucząc obiektowych zasad społeczności, która w dużej mierze przeniosła się z C), ponieważ a także praktyczne lekcje wyciągnięte z języków, które pojawiły się wcześniej (w tym Java i jej niemal fanatyczne posłuszeństwo wobec wszechmogącego Obiektu, kiedy stary, dobry wskaźnik funkcji w stylu C ++ wykonałby zadanie znacznie czystiej i nie byłby mniej obiektowy zorientowany).

Ze względów antymonopolowych stwardnienie rozsiane jest ostrożne, aby nie zostać zbyt mocno zakłóconym na innych głównych platformach, takich jak Android, Mac OSX / iOS i Linux; jednak rzeczywiście istnieją zespoły rozwijające się dla wszystkich trzech platform. Istnieje opracowana przez MS wersja pakietu Office dla OSX, istnieje wiele aplikacji, w tym aplikacje Office Interop na iOS i Android, Skype (obecnie produkt Microsoft) działa na Linuksie, a Microsoft nawet widział, że przyczynia się do jądra Linuksa (głównie w sposób myślenia o wirtualizacji).

System operacyjny Windows jest dostępny dla różnych typów procesorów, dziś głównie x64, x86, Intel, ARM.

CIL / CLR jest niezależny od platformy sprzętowej - różnice te są „usuwane” przez środowisko wykonawcze IL. Na przykład zestaw .NET skompilowany dla „dowolnego procesora” może zwykle być wykonywany na Win64 jako proces 64-bitowy, a Win32 jako proces 32-bitowy, bez potrzeby dostarczania różnych plików wykonywalnych.

Co więcej, CIL pozwala na przechowywanie metadanych w zestawach, co nie jest łatwe w przypadku natywnych bibliotek DLL (możliwe jest oczywiście, że MS zrobił to wcześniej z komponentami COM, ale ta technologia nigdy nie była tak łatwa w obsłudze jak komponenty .NET). To sprawia, że ​​tworzenie komponentów oprogramowania jest o wiele prostsze i stanowi podstawę refleksji / introspekcji we wszystkich językach .NET.