Чому WinRT не управляється? [зачинено]

164

Windows 8 представляє WinRT, який схожий на .NET, але некерований. Чому це некеровано? Це проблема продуктивності? Це означає, що збір сміття не підходить для API нижчого рівня?

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

Відповіді:

190

WinRT - це заміна віковому вінапі на базі С. Це 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. Афаїку, на сьогоднішній день жодна робота над керованими компіляторами не проводилася.

EDIT: Ларрі Остерман, відомий програміст та блогер Microsoft, залишив досить хороший коментар у видаленій відповіді. Я цитую його для збереження:

WinRT не управляється, тому що ОС не керована. І проектуючи WinRT таким, яким він був розроблений, він набуває здатності виражатися на багатьох різних мовах, а не тільки на C ++, C # та JS. Наприклад, я міг легко бачити набір модулів Perl, які реалізують API WinRT, які працюють на робочому столі. Якби ми реалізували це у .Net, це було б надзвичайно важко

— Ганс Пасант
джерело
14
Я не знаю про компілятори, але я майже впевнений, що проекція WinRT .NET провела багато роботи над CLR. Вони, можливо, повторно використали код COM Interop, але є й відмінності (наприклад, IInspectableви можете робити такі речі, як запит об’єкта на його фактичний тип класу чи список усіх підтримуваних інтерфейсів, а з файлами winmd можна спроектувати метадані WinRT для всього цього у відображення ). І файли winmd не одразу можуть бути використані як інтероп-збірки, і CLR повинен спеціально обробляти їх.
— Павло Мінаєв
5
Не впевнений, ви ігноруєте слона. IInspectable - це заміна IDispatch, який застряг у 1997 році. Ви працюєте для Microsoft, не соромтеся роздавати тут деякі секрети :)
— Hans Passant
13
Була проведена робота на всіх трьох мовах для підтримки мовних прогнозів.
— ReinstateMonica Ларрі Остерман
14
Я б стверджував, що зараз "найкращим прив'язкою для WinRT" є насправді C #. Прив'язка CLR оптимізована навіть за межами досить швидкого взаємодії з COM, а мови .NET у попередньому перегляді розробників вже реалізують чудову підтримку всюдисущих функцій асинхронізації з функцією "очікування". У кількох демонстраціях код C # зробив набагато більше, ніж вибірки C ++, і працював легше. Можливо, пізніше C ++ отримає розширення помічника async, але в цій версії C ++ async виглядало жахливо. І у вас менше шансів на витік довгострокової пам'яті з CLR, що збирає сміття, ніж циклічна C ++ реалізація. C # FTW!
— Govert
13
@Hans: 3-я проекція - це CLR для всіх мов CLR (насамперед C # і VB). Також WinJS не є проекцією, це набір бібліотек підтримки. Проекція безпосередньо вбудована в двигун Chakra JS.
— ReinstateMonica Ларрі Остерман
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 є недостатнім для реальної роботи OOP, а претензії Stroustrup на C ++, що дають вам «переносимість», є дуже обережними з огляду на робочу реальність. Дивіться http://webmechs.com/webpress/2011/11/c-versus-objective-c-as-api-substrate/

— Андц
джерело
Оновлене посилання для думок Bjarne про C ++ / CLI: stroustrup.com/bs_faq.html#CppCLI
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.