WinRT가 관리되지 않는 이유는 무엇입니까? [닫은]

164

Windows 8에는 .NET과 유사하지만 관리되지 않는 WinRT가 도입되었습니다. 관리되지 않는 이유는 무엇입니까? 성능 문제입니까? 가비지 수집이 하위 수준 API에 적합하지 않다는 것을 의미합니까?

c# .net windows-8 windows-runtime

— 사용자
소스

전화 를 끊는 것만 큼 나쁜 전화 였습니다 . 당신은 이제 참고 문헌과 출처를 고집하고, 질문을 닫아서 그것을 잘라냅니다. 이제 작업 한 프로그래머로부터 훌륭한 소스 를 삭제 했습니다.

— Hans Passant

나는 이것이 실제 프로그래밍 질문을 다루지 않기 때문에 주 제외로 투표했습니다. 호기심 일뿐입니다. 이 질문의 결과로 프로그래머는 코드를 변경하지 않습니다.

— Raymond Chen

@Kev 그 추론으로 "지구는 어떻게 형성 되었는가?" 과학계에서는 많은 종교적 추론을 불러 일으켰 기 때문에 끔찍했을 것입니다 이 질문에 대한 정답이 있습니다. 단지 많은 정답을 끌어 당기는다고해서 이것이 나쁜 질문이라는 의미는 아닙니다. 하지만이 질문을 왜 P.SE로 옮기지 않겠습니까?

— Rei Miyasaka

@casperOne 많은 개발자들에게 합법적 인 "화이트 보드"질문입니다. 우리는 아마도 결정에 대한 기술적 이유를 알고 싶기 때문에 다른 곳에 동일한 추론을 적용 할 수 있습니다. 가비지 수집기가 프로파일 링하기 어렵 기 때문입니까? 저수준 하드웨어 추상화에보다 쉽게 액세스 할 수 있기 때문입니까? 기술적 인 이유가 없다면 그것은 불행히도 불행한 일입니다. 그러나 그것은 질문 자체의 품질과 전혀 관련이 없습니다.

— Rey Miyasaka

@HansPassant에 동의합니다. 이 질문은 다시 열고 유효한 것으로 취급해야합니다. "관리되지 않는 이유는 무엇입니까?" WinRT 기초와 관련하여 매우 좋은 질문입니다.

— Rob Perkins

답변:

190

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 .NET 프로젝션은 CLR에서 많은 작업을 수행했다고 확신합니다. COM Interop 코드를 재사용했을 수도 있지만 차이점도 있습니다 (예 : IInspectable실제 클래스 유형 또는 지원되는 모든 인터페이스 목록에 대한 객체 쿼리와 같은 작업을 수행 할 수 있으며 winmd 파일을 사용하면 모든 것에 대한 WinRT 메타 데이터를 리플렉션에 투영 할 수 있음) ). 또한 winmd 파일은 interop 어셈블리로 즉시 사용할 수 없으며 CLR은이를 특수하게 처리해야합니다.

— Pavel Minaev

확실하지 않습니다, 당신은 코끼리를 무시하고 있습니다. IInspectable은 1997 년에 중단 된 IDispatch를 대체합니다. Microsoft에서 근무하고 있으며 여기에서 비밀을 알려 주시기 바랍니다. :)

— Hans Passant

언어 예측을 지원하기 위해 3 개 언어 모두에서 수행 된 작업이있었습니다.

— ReinstateMonica Larry Osterman

나는 현재 'WinRT에 가장 적합한 바인딩'은 실제로 C #이라고 주장합니다. CLR 바인딩은 매우 빠른 COM interop 이상으로 최적화되었으며, dev 미리보기의 .NET 언어는 이미 'await'를 사용하여 유비쿼터스 비동기 기능을 지원합니다. 몇 가지 데모에서 C # 코드는 C ++ 샘플보다 훨씬 많은 작업을 수행했으며 더 쉽게 작동했습니다. 아마도 나중에 C ++은 비동기 도우미 확장을 얻지만이 버전에서는 C ++ 비동기가 끔찍한 것처럼 보였습니다. 또한주기 문제가있는 C ++ 구현보다 가비지 수집 CLR에서 장기 메모리가 누출 될 가능성이 적습니다. C # FTW!

— Govert

@Hans : 세 번째 투영법은 모든 CLR 언어 (주로 C # 및 VB)의 CLR입니다. 또한 WinJS는 프로젝션이 아니며 지원 라이브러리 세트입니다. 이 투영은 Chakra JS 엔진에 직접 내장되어 있습니다.

— ReinstateMonica Larry Osterman

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/를 참조 하십시오

— 안즈
소스

C ++ / CLI에 비얀의 생각에 대한 업데이트 링크 : stroustrup.com/bs_faq.html#CppCLI