Windows 8에는 .NET과 유사하지만 관리되지 않는 WinRT가 도입되었습니다. 관리되지 않는 이유는 무엇입니까? 성능 문제입니까? 가비지 수집이 하위 수준 API에 적합하지 않다는 것을 의미합니까?
답변
WinRT는 것입니다 대체 오래된 C 기반 WINAPI합니다. 많은 런타임 환경에서 사용할 수 있어야하는 API입니다. 20 년 전, C api는 다루기 쉬웠습니다. 그 이후로 COM은 1990 년대 후반에 보편적 인 접착제가되었습니다. 실제로 Windows에서 일반적으로 사용되는 모든 언어 런타임은 COM을 지원합니다.
가비지 콜렉터는 언어 런타임 구현 세부 사항입니다. 예를 들어 .NET 용 수집기는 Javascript 용 수집기와 매우 다릅니다. 둘 중 하나에서 생성 된 기본 개체는 수집기의 매우 엄격한 규칙을 준수해야합니다. 이는 각 언어 런타임에 고유 한 WinRT 버전을 작성해야했음을 의미합니다. 마이크로 소프트만큼 큰 회사조차도 모든 언어 바인딩에 대해 특정 WinRT 버전을 만들고 지원할 여유가없는 것은 아닙니다. 이러한 언어가 이미 COM을 지원한다는 점을 고려할 필요도 없습니다.
COM이 명시 적 메모리 관리와 함께보다 효율적으로 작동하기 때문에 WinRT에 대한 최상의 바인딩은 C ++입니다. 자동으로 만드는 새로운 C ++ 컴파일러 확장 프로그램의 충분한 도움으로 C ++ / CLI와 같은 구문을 사용하여 _com_ptr_t와 유사하게 피할 수 있습니다. CLR에는 이미 뛰어난 COM interop 지원 기능이 있으므로 관리되는 언어에 대한 바인딩은 비교적 간단합니다. WinRT는 또한 .NET의 메타 데이터 형식을 채택했습니다. Afaik, 오늘날 관리되는 컴파일러에 대한 작업은 전혀 없습니다.
편집 : 잘 알려진 Microsoft 프로그래머 및 블로거 인 Larry Osterman은 삭제 된 답변에 다소 좋은 의견을 남겼습니다. 보존하기 위해 여기에 인용하겠습니다.
OS가 관리되지 않기 때문에 WinRT가 관리되지 않습니다. 또한 WinRT를 설계된 방식으로 설계함으로써 C ++, C # 및 JS뿐만 아니라 다양한 언어로 표현할 수 있습니다. 예를 들어 데스크톱에서 작동하는 WinRT API를 구현하는 Perl 모듈 세트를 쉽게 볼 수 있습니다. 우리가 .Net에서 그것을 구현했다면, 그것은 매우 어려웠을 것입니다
답변
WinRT는 Windows 용 가장 낮은 수준의 개발자 액세스 가능 API 인 Win32를 대체하기 때문에 관리되지 않습니다. 관리되지 않는 API는 여전히 개발자에게 노출 될 수있는 가장 잠재적으로 성능이 뛰어난 API이므로 관리되는 API를 항상 그 위에 배치 할 수 있다는 추론이 이루어집니다. 이는 정확히 ‘투영’이하는 일입니다.
또한 C ++ 개발자가 C ++ / CLI가 소개 한 후프를 뛰어 넘지 않고 WinRT를 사용할 수 있음을 의미합니다 ( http://www2.research.att.com/~bs/bs_faq.html#CppCLI 참조 ). WinRT를 사용하려면 COM을 공부해야합니다.
진짜 질문은 ‘COM이 왜 필요한가? Microsoft가 왜 발명해야합니까? ‘ COM의 모든 추가 기능이없는 일반 C ++은 실제 OOP 작업에 적합하지 않으며 Stroustrup의 C ++에 대한 ‘휴대 성’을 제공하는 주장은 작업 현실에 비추어 볼 때 매우 불분명합니다. http://webmechs.com/webpress/2011/11/c-versus-objective-c-as-api-substrate/를 참조 하십시오
