В Windows 8 представлен WinRT, который похож на .NET, но неуправляемый. Почему он неуправляемый? Это проблема производительности? Означает ли это, что сбор мусора не подходит для API более низкого уровня?
Почему WinRT неуправляемый?
Ответ 1
WinRT является заменой для вековой C-based Winapi. Это api, который должен использоваться во многих средах исполнения. Назад 20 лет назад, C api было относительно легко interop с. С тех пор это произошло, и COM стал универсальным клеем в последней половине 1990-х годов. Практически любой язык, используемый в Windows, поддерживает COM.
Сборщик мусора - это подробная информация о реализации времени выполнения языка. Коллекционер для .NET очень отличается от сборщика для Javascript, например. Собственные объекты, созданные в обоих, должны соблюдать очень строгие правила коллектора. Это, в свою очередь, означает, что им пришлось бы создавать версии WinRT, специфичные для каждой языковой среды исполнения. Этого не будет делать, даже компания, столь же крупная, как Microsoft, не может позволить себе создавать и поддерживать определенную версию WinRT для каждого языкового связывания. Это также не обязательно, учитывая, что эти языки уже поддерживают COM.
В настоящее время лучшим связыванием для WinRT является С++, поскольку COM работает более эффективно с явным управлением памятью. С большой помощью от новых расширений компилятора С++, которые делают его автоматическим, очень похожи на _com_ptr_t старого с синтаксисом С++/CLI, чтобы избежать его. Связывание с управляемыми языками относительно просто, так как CLR уже имеет отличную поддержку COM-взаимодействия. WinRT также принял формат метаданных .NET. Afaik, на сегодняшний день никакой работы не было сделано на управляемых компиляторах.
EDIT: Ларри Остерман, известный программист и блоггер Microsoft, оставил довольно хороший комментарий в теперь удаленном ответе. Я приведу его здесь, чтобы сохранить его:
WinRT неуправляема, поскольку ОС неуправляема. И, создав WinRT так, как он был разработан, он получает способность выражаться на разных языках, а не только на С++, С# и JS. Например, я мог легко увидеть набор модулей Perl, которые реализуют API-интерфейсы WinRT, которые работают на рабочем столе. Если бы мы реализовали его в .Net, это было бы чрезвычайно сложно
Ответ 2
WinRT неуправляем, потому что он предназначен для замены Win32 - API-интерфейса, доступного разработчику самого низкого уровня для Windows. Неуправляемый API по-прежнему является наиболее потенциально потенциальным, который может быть представлен разработчику, и рассуждения состоят в том, что всегда можно будет обернуть управляемый API поверх него, что и делает "прогнозы".
Это также означает, что разработчики С++ могут использовать WinRT, не перескакивая через обручи, которые вводит С++/CLI (см. http://www2.research.att.com/~bs/bs_faq.html#CppCLI). Это означает хотя вам все равно придется изучать COM, если вы хотите использовать WinRT.
Реальный вопрос: "зачем нужен COM? зачем Microsoft это изобретать? Поскольку простой С++ без всех дополнительных возможностей COM неадекватен для реальной работы ООП, а претензии Stroustrup на С++, дающие вам" переносимость ", очень неискренны в свете рабочей реальности. См. http://webmechs.com/webpress/2011/11/c-versus-objective-c-as-api-substrate/