Почему WinRT неуправляем? [закрыто]

165

Windows 8 представляет WinRT, который похож на .NET, но неуправляемый. Почему это неуправляемо? Это проблема с производительностью? Означает ли это, что сборка мусора не подходит для API более низкого уровня?

c# .net windows-8 windows-runtime user380719
источник
56
Это был плохой звонок , такой же плохой, как и закрытие. Теперь вы настаиваете на ссылках и источниках, вы обрезали это раньше, закрыв вопрос. Теперь вы удалили отличные источники от программистов, которые работали над этим.
Ганс Пассант
9
Я проголосовал как не по теме, поскольку это не решает практический вопрос программирования. Это просто любопытство. Ни один программист не собирается менять свой код в результате этого вопроса.
Рэймонд Чен,
17
@Kev По этой причине такие вопросы, как "как была сформирована планета Земля?" было бы абсолютно ужасно в научном сообществе, потому что это вызвало много религиозных спекуляций. Есть хорошие ответы на этот вопрос - только потому, что он привлекает много плохих ответов, не означает, что это плохой вопрос. Правда, почему бы просто не перенести этот вопрос в P.SE?
Рей Миясака
22
@casperOne Это законный вопрос «доски» для многих разработчиков - мы хотим знать, по-видимому, технические причины решения, чтобы мы могли применить те же рассуждения в другом месте. Это потому, что сборщик мусора сложно профилировать? Потому что это упрощает доступ к аппаратным абстракциям более низкого уровня? Если технических причин нет, то это просто прискорбно - но это никак не связано с качеством самого вопроса.
Рей Миясака
7
Я согласен с @HansPassant; этот вопрос должен быть вновь открыт и рассматриваться как действительный. "Почему это неуправляемо?" Это очень хороший вопрос относительно основ WinRT.
Роб Перкинс

Ответы:

191

WinRT является заменой для старого Winapi на основе Си. Это API, который должен использоваться во многих средах выполнения. Еще 20 лет назад с C api было относительно легко взаимодействовать. С того времени COM стал универсальным клеем во второй половине 1990-х годов. Практически любой язык, обычно используемый в Windows, поддерживает COM.

Сборщик мусора - это деталь реализации языка исполнения. Например, сборщик для .NET сильно отличается от сборщика для Javascript. Нативные объекты, созданные в любом из них, должны соблюдать очень строгие правила коллекционера. Это, в свою очередь, означает, что им пришлось бы создавать версии WinRT, специфичные для каждой языковой среды выполнения. Этого не произойдет, даже такая крупная компания, как Microsoft, не может позволить себе создавать и поддерживать определенную версию WinRT для каждой языковой привязки. В этом нет необходимости, учитывая, что эти языки уже поддерживают COM.

На данный момент лучшим связыванием для WinRT является C ++, поскольку COM работает более эффективно с явным управлением памятью. С большой помощью новых расширений компилятора C ++, которые делают его автоматическим, очень похожим на _com_ptr_t старого с C ++ / CLI-подобным синтаксисом, чтобы избежать этого. Привязка к управляемым языкам относительно проста, поскольку CLR уже имеет отличную поддержку взаимодействия COM. WinRT также принял формат метаданных .NET. Afaik, на сегодняшний день не было никакой работы над управляемыми компиляторами.

РЕДАКТИРОВАТЬ: Ларри Остерман, известный программист и блоггер Microsoft, оставил довольно хороший комментарий в уже удаленном ответе. Я приведу это здесь, чтобы сохранить его:

WinRT неуправляем, потому что ОС неуправляема. А проектируя WinRT так, как он был спроектирован, он получает возможность выражаться на многих языках, а не только на C ++, C # и JS. Например, я мог легко увидеть набор модулей Perl, которые реализуют WinRT API, которые работают на рабочем столе. Если бы мы реализовали это в .Net, это было бы чрезвычайно сложно

Ганс Пассант
источник
14
Я не знаю о компиляторах, но я почти уверен, что проектирование WinRT .NET проделало большую работу над CLR. Возможно, они повторно использовали код COM Interop, но есть и различия (например, IInspectableпозволяет вам делать такие вещи, как запрос объекта на предмет его фактического типа класса или списка всех поддерживаемых интерфейсов, а с помощью файлов winmd можно проецировать метаданные WinRT для всего этого в Reflection. ). И файлы winmd не могут быть сразу использованы как сборки взаимодействия, CLR должен обрабатывать их специально.
Павел Минаев
5
Не уверен, что вы игнорируете слона. IInspectable - это замена для IDispatch, который застрял в 1997 году. Вы работаете на Microsoft, не стесняйтесь раскрывать некоторые секреты здесь :)
Ганс Пассант
13
Была проделана работа на всех 3 языках для поддержки языковых прогнозов.
Восстановить Монику Ларри Остерман
14
Я бы сказал, что сейчас «лучшим связыванием для WinRT» является C #. Привязка CLR оптимизирована даже за пределами довольно быстрого COM-взаимодействия, а языки .NET в предварительном просмотре dev уже реализуют превосходную поддержку вездесущих асинхронных функций с помощью await. В некоторых демонстрациях код C # сделал намного больше, чем примеры C ++, и работал более легко. Возможно, позже C ++ получит расширение async helper, но в этой версии C ++ async выглядел ужасно. И у вас меньше шансов утратить долгосрочную память из CLR для сбора мусора, чем из-за проблематичной реализации C ++. C # FTW!
Говерт
13
@Hans: 3-я проекция - это CLR для всех языков CLR (прежде всего C # и VB). Также WinJS - это не проекция, это набор библиотек поддержки. Проекция напрямую встроена в двигатель Chakra JS.
Восстановить Монику Ларри Остерман
25

WinRT неуправляем, потому что он предназначен для замены Win32 - API самого низкого уровня, доступного для разработчиков для Windows. Неуправляемый API по-прежнему является наиболее потенциально производительным, который может быть представлен разработчику, и есть основания полагать, что всегда будет возможно обернуть управляемый API поверх него, что в точности и делают «проекции».

Это также означает, что разработчики C ++ могут использовать WinRT, не перепрыгивая через обручи, которые вводит C ++ / CLI (см. Http://www2.research.att.com/~bs/bs_faq.html#CppCLI ). должен изучить COM, если вы хотите использовать WinRT.

На самом деле вопрос в том, зачем нужен COM? почему Microsoft должна была его изобрести? Потому что простой C ++ без всех дополнительных возможностей COM не подходит для реальной ООП-работы, а претензии Stroustrup на C ++, дающие вам «переносимость», очень неискренни в свете рабочей реальности. Смотрите http://webmechs.com/webpress/2011/11/c-versus-objective-c-as-api-substrate/

Andz
источник
Обновлена ​​ссылка на мысли Бьярна