Чому в .NET потрібні CIL та CLR?

Я бачив це гарне зображення тут . Я дізнався, що всі компілятори, які підтримують .net мову, перетворюють вихідний код у CILформат. Тепер Microsoft ніколи не приносить .NETдля всіх операційних систем написання CLR для всіх операційних систем. Тоді навіщо зберігати такий проміжний формат коду та CLR для виконання цього CIL. Хіба це не головний біль боротися. Чому Microsoft обрала такий?

EDIT Ця своєрідна архітектура має свою ціну. Це знизить продуктивність, чи не так? Java робить це для підтримки незалежності платформи, з якої причини .NET це робить? Чому б не зберегти простий звичайний C, як компілятор. Будь-який спосіб також зажадає компілятора для перетворення коду в CIL, якщо мені потрібно буде додати будь-яку нову мову, єдина різниця, яку це зробить, - це цільова мова. Тат все.

Тому що їм потрібно написати лише один компілятор для C # в CIL - що є важкою частиною. Зробити інтерпретатора (або частіше - компілятора Just-In-Time) для CIL на платформу порівняно просто порівняно з написанням компілятора з виконуваного коду від C # до (на платформу).

Крім цього, час виконання може обробляти все, що компілюється в CIL. Якщо ви хочете нову мову (наприклад, F #), вам потрібно написати лише один компілятор, і ви автоматично магічно отримаєте всю підтримку платформи для речей .NET.

О, і я можу взяти .NET dll і запустити це на Windows або на Linux через Mono без перекомпіляції (якщо припустити, що всі мої залежності задоволені).

Щодо продуктивності, то це дискусійно. По суті, є "попередні компілятори", які беруть CIL і роблять нативні бінарні файли. Інші стверджують, що вчасно встановлені компілятори можуть зробити оптимізацію, що статичні компілятори просто не можуть. На мій досвід, багато що залежить від того, чим займається ваша програма та на якій платформі ви працюєте (переважно, наскільки хороший JITer на цій платформі). Мені надзвичайно рідко трапляється сценарій, коли .NET був недостатньо хорошим .

.NET має проміжну мову (CIL / MSIL) та реалізовані для платформи реалізацію незалежної від платформи часу (CLR) з тієї ж причини, що і Java. Microsoft задумала C # безпосередньо конкурувати з Java, і це робиться на ОС, на які Microsoft націлена (власна).

Переваги, навіть незважаючи на те, що .NET підтримується лише на платформах Windows (або інших ОС, у яких є .NET, що працює як Mono / Linux), схожі на Java:

• Керована обсяг пам’яті - на відміну від некерованого C / C ++, розробникам C # / VB.NET не потрібно турбуватися про строгий контроль життя об'єкта. Як і Java, CLR має сміттєзбірник, який автоматично звільняє об'єкти в купі, які залишають сферу застосування. Хоча це може здатися незначним для тих, хто звик до некерованого виконання, але це є надзвичайно вторинною перевагою, що відлякує "чорну магію" арифметики вказівника, що так часто зустрічається в C / C ++.
• Незалежність від платформи - Windows Vista та Windows 7 працюють по-різному від Windows XP. Windows 8 працює інакше. Версії Windows Mobile, включаючи Windows 8 Mobile, знову працюють по-різному. Різне обладнання, інша архітектура, різні можливості. Хоча цільове середовище все ще має значення для розробника .NET, обсяг спеціалізованих знань значно скорочується порівняно з тим, що необхідно знати, щоб створити сумісну програму C / C ++ для всіх цих ОС. AC # dev отримує набагато більше безкоштовно.
• Підтримка веб-додатків - я ще не бачив веб-застосунку, орієнтованого на клієнта, написаного на сервер, написаного з нуля на C ++. Веб- сервер , звичайно, Apache, ISS, всі вони, як правило, працюють проти некерованого часу виконання з міркувань швидкості та ефективності. Однак C ++ не є мовою, що використовується для створення веб-додатків. C # є (як і Java). Він був розроблений з самого початку, щоб підтримувати парадигму Microsoft ASP наступного покоління. Це код, призначений для запуску в пісочниці; яка пісочниця (плагін ASP.NET до ISS або CLR на робочому столі) є відносно неважливою.
• Незалежність мови / часу виконання - Компілятор C ++ приймає вихідний код C ++ і виробляє код складання для однієї архітектури процесора, використовуючи одну машинну мову. Для підтримки іншої архітектури та / або машинної мови повинен бути записаний абсолютно новий компілятор (і повинен бути зібраний абсолютно новий набір бібліотек виконання). Компілятор AC # приймає вихідний код C # і виробляє CIL, який специфічний для обладнання JITer переводить на машинний код. Той же JITer може перекладати будь-яку програму CIL незалежно від мови джерела (а їх декілька; C #, VB.NET, F # і безліч мовних портів "Iron", таких як IronHaskell, IronRuby, IronLisp тощо). Цей же компілятор може перетворити одну мову в CIL, якою може запускати будь-який JITer, незалежно від обладнання.
• Зосередьтеся на "правильному" коді - для розробників C ++ існує багато "правильних" способів зробити щось, залежно від того, що є найважливішим; ефективність пам'яті, ефективність процесора, незалежність обладнання, незалежність ОС тощо. Код може виглядати кардинально різним, коли кожне з них є пріоритетним. C # була розроблена групою, яка прийняла до уваги концептуальні уроки Фоулера та його колег (які працювали над реформуванням дизайну коду у спільноті C ++, викладаючи об'єктно-орієнтовані принципи для спільноти, яка значною мірою перейшла до неї із С), як а також практичні уроки, засвоєні мовами, що були раніше (включаючи Java, і її майже фанатичне послух всемогутньому Об'єкту, коли старий добрий вказівник функції стилю C ++ зробив би цю роботу набагато чіткіше і не був би меншим об'єктом, орієнтований).

З антимонопольних причин MS обережно не сприймає «занадто сильного втручання» в інші основні платформи, такі як Android, Mac OSX / iOS та Linux; однак у нього дійсно є команди, що розробляють для всіх трьох цих платформ. Існує розроблена MS версія версії Office для OSX, є численні додатки, включаючи додатки Office interop для iOS та Android, Skype (зараз продукт Microsoft) працює на Linux, і Microsoft навіть бачила внесок у ядро ​​Linux (насамперед у віртуалізація мислення).

ОС Windows доступна для різних типів процесора, сьогодні це в основному x64, x86, Intel, ARM.

CIL / CLR не залежить від цієї апаратної платформи - ці відмінності "абстрагуються" середовищем виконання IL. Наприклад, збірка .NET, складена для "будь-якого процесора", як правило, може виконуватися на Win64 як 64-бітний процес, а Win32 як 32-бітний процес без необхідності надання різних виконуваних файлів.

Крім того, CIL дозволяє зберігати метадані в збірках, що неможливо з рідними DLL (можливо, звичайно, MS це робило раніше з компонентами COM, але ця технологія ніколи не була такою простою в обробці, як компоненти .NET). Це робить створення програмних компонентів набагато простішим і є основою рефлексії / самоаналізу на всіх мовах .NET.