.NET에서 CIL 및 CLR이 필요한 이유는 무엇입니까?

나는이 멋진 이미지를 여기에서 보았다 . .net 언어를 지원하는 모든 컴파일러가 소스 코드를 CIL형식으로 변환한다는 것을 알았습니다 . 이제 Microsoft는 .NET모든 운영 체제에 대해 CLR을 작성하여 모든 운영 체제를 도입하지 않습니다. 그렇다면 왜 그런 CIL을 실행하기 위해 중간 코드 형식과 CLR을 유지해야 하는가? 다루어야 할 두통이 아닙니다. Microsoft가 왜 이렇게 선택 했습니까?

편집 이 좀 아키텍처는 그 가격이 있습니다. 성능이 저하되지 않습니까? Java는 플랫폼 독립성을 유지하기 위해 이것을 수행합니다. .NET이 어떤 이유로합니까? 컴파일러와 같은 간단한 일반 C를 유지하지 않겠습니까? 새로운 언어를 추가해야 할 경우 컴파일러는 코드를 CIL로 변환해야합니다. 대상 언어와의 유일한 차이점은 대상 언어입니다. 문신이 전부 야

C #에 대해 하나의 컴파일러 만 CIL에 작성하면되기 때문에 어려운 부분입니다. C #에서 (플랫폼 별) 실행 코드로 컴파일러를 작성하는 것과 비교하여 플랫폼 당 CIL에 대한 인터프리터 (또는 더 자주 Just-In-Time 컴파일러)를 만드는 것은 비교적 쉽습니다.

그 외에도 런타임은 CIL로 컴파일되는 모든 것을 처리 할 수 ​​있습니다. F #과 같은 새로운 언어를 원한다면 하나의 컴파일러 만 작성 하면 .NET이 지원하는 모든 플랫폼 지원을 자동으로 수행 할 수 있습니다.

그리고 .NET dll을 가져 와서 다시 컴파일하지 않고 Mono를 통해 Windows 또는 Linux에서 실행할 수 있습니다 (모든 종속성이 충족되었다고 가정).

성능에 관해서는 논쟁의 여지가 있습니다. 본질적으로 CIL을 취해 네이티브 바이너리를 만드는 "컴파일러"가 있습니다. 다른 사람들은 적시 컴파일러가 정적 컴파일러가 할 수없는 최적화를 할 수 있다고 주장합니다. 내 경험상, 그것은 당신의 응용 프로그램이 무엇을하고 있고 어떤 플랫폼을 실행하고 있는지 (주로 JITer가 그 플랫폼에서 얼마나 좋은지) 많은 것에 달려 있습니다. .NET이 충분 하지 않은 시나리오를 시작하는 것은 극히 드 rare니다 .

.NET에는 Java와 동일한 이유로 CIL / MSIL (중간 언어) 및 CLR (플랫폼 독립적 런타임)의 플랫폼 별 구현이 있습니다. Microsoft는 C #이 Java와 직접 경쟁하도록 의도했으며, Microsoft가 목표로하는 OS (자체)에서 C와 경쟁합니다.

.NET은 Windows 플랫폼 (또는 Mono / Linux와 같은 .NET 작동 방식을 가진 다른 OS)에서만 지원되지만 Java와 유사합니다.

• 관리되는 메모리 런타임-관리되지 않는 C / C ++와 달리 C # / VB.NET 개발자는 개체 수명을 엄격하게 제어 할 필요가 없습니다. Java와 마찬가지로 CLR에는 범위를 벗어나는 힙의 객체를 자동으로 해제하는 가비지 수집기가 있습니다. 이것은 관리되지 않는 런타임에 익숙한 사람에게는 미미한 것처럼 보일 수 있지만 C / C ++에서 일반적으로 사용되는 포인터 산술의 "블랙 매직"을 권장하지 않는 가장 큰 이점이 있습니다.
• 플랫폼 독립성-Windows Vista 및 Windows 7은 Windows XP와 다르게 작동합니다. Windows 8은 여전히 ​​다르게 작동합니다. Windows 8 Mobile을 포함한 Windows Mobile 버전은 다시 다르게 작동합니다. 다른 하드웨어, 다른 아키텍처, 다른 기능. 대상 환경은 여전히 ​​.NET 개발자에게 중요하지만 이러한 모든 OS에 대해 호환 가능한 C / C ++ 프로그램을 빌드하는 것으로 알려진 것보다 전문 지식의 양이 훨씬 줄어 듭니다. AC # dev는 무료로 더 많은 것을 얻습니다.
• 웹 응용 프로그램 지원-아직 C ++로 작성된 클라이언트 용 서버 스크립트 웹 응용 프로그램은 아직 보지 못했습니다. 물론 웹 서버 , Apache, ISS는 모두 속도 / 효율적인 이유로 관리되지 않는 런타임에 대해 실행됩니다. 그러나 C ++는 웹 응용 프로그램을 작성하는 데 사용되는 언어가 아닙니다. C #은 Java와 동일합니다. 처음부터 차세대 Microsoft ASP 패러다임을 지원하도록 설계되었습니다. 이것은 샌드 박스에서 실행되도록 설계된 코드입니다. 어느 샌드 박스 (ISS에 대한 ASP.NET 플러그인 또는 "데스크톱"CLR)는 상대적으로 중요하지 않습니다.
• 언어 / 런타임 독립성-C ++ 컴파일러는 C ++ 소스 코드를 사용하여 하나의 기계어를 사용하여 하나의 프로세서 아키텍처에 대한 어셈블리 코드를 생성합니다. 다른 아키텍처 및 / 또는 기계 언어를 지원하려면 완전히 새로운 컴파일러를 작성해야하며 완전히 새로운 런타임 라이브러리 세트를 컴파일해야합니다. AC # 컴파일러는 C # 소스 코드를 사용하여 하드웨어 별 JITer가 기계 코드로 변환하는 CIL을 생성합니다. 동일한 JITer는 소스 언어에 관계없이 모든 CIL 프로그램을 번역 할 수 있습니다 (C #, VB.NET, F # 및 IronHaskell, IronRuby, IronLisp 등과 같은 여러 "Iron"언어 포트가 있습니다). 동일한 컴파일러는 하드웨어에 관계없이 모든 JITer가 실행할 수있는 하나의 언어를 CIL로 변환 할 수 있습니다.
• "올바른"코드에 집중-C ++ 개발자에게는 가장 중요한 것에 따라 무언가를하는 "올바른"방법이 많이 있습니다. 메모리 효율성, CPU 효율성, 하드웨어 독립성, OS 독립성 등 각 코드가 우선 순위 인 경우 코드가 크게 다르게 보일 수 있습니다. C #은 다음과 같이 Fowler와 그의 동료 (C ++ 커뮤니티 내에서 객체 지향적 원칙을 교육함으로써 C ++ 커뮤니티 내에서 코드 설계를 개혁함으로써 코드 설계를 개혁하기 위해 노력했던)의 개념적 교훈을 염두에 둔 그룹에 의해 설계되었습니다. 이전의 언어들 (자바와 전능 한 객체에 대한 거의 광신적 인 순종을 포함하여, 오래된 C ++ 스타일의 함수 포인터가 훨씬 더 깨끗하고 일을 덜 할 때) 지향).

독점 금지 문제로 인해 MS는 Android, Mac OSX / iOS 및 Linux와 같은 다른 주요 플랫폼에서 너무 "중단"되지 않도록주의합니다. 그러나 실제로이 세 가지 플랫폼 모두를 위해 팀을 개발하고 있습니다. MS 용으로 개발 된 Office for OSX 버전이 있으며 iOS 및 Android 용 Office interop 앱, Skype (현재 Microsoft 제품)는 Linux에서 실행되며 Microsoft는 Linux 커널에 주로 기여하는 것으로 나타났습니다. 가상화 사고 방식).

Windows OS는 오늘날 대부분 x64, x86, Intel, ARM 등 다양한 CPU 유형에 사용할 수 있습니다.

CIL / CLR은 해당 하드웨어 플랫폼과 독립적입니다. 이러한 차이점은 IL 실행 환경에 의해 "추상화"됩니다. 예를 들어 "모든 CPU"용으로 컴파일 된 .NET 어셈블리는 일반적으로 다른 실행 파일을 제공 할 필요없이 Win64에서 64 비트 프로세스로, Win32를 32 비트 프로세스로 실행할 수 있습니다.

또한 CIL을 사용하면 네이티브 DLL로는 쉽게 수행 할 수없는 어셈블리에 메타 데이터를 저장할 수 있습니다 (물론 MS는 COM 구성 요소를 사용하기 전에이 작업을 수행 할 수 있었지만 해당 기술은 .NET 구성 요소만큼 다루기가 쉽지 않았습니다). 따라서 소프트웨어 구성 요소를 훨씬 간단하게 만들 수 있으며 모든 .NET 언어에서 리플렉션 / Introspection 의 기초가 됩니다.