- 主题:C++/WinRT为什么搞一套自己的基础类型，不适用stl？
既然要使用标准c++了，为什么还要自己搞一套
增加程序员的转换负担？
性能不是问题啊，都用uwp做ui了，就不在乎winrt自己转换的开销了
--
FROM 223.72.62.*
com性能很低啊， 我还以为是直接用c++封装的win32接口
如果是com的话，估计还是用com封装的dotnet
【 在 z16166 的大作中提到: 】
: WinRT(windows runtime)是用COM实现的，多种语言如c#、c++等都能调用。
: C++/WinRT是方便C++来调用WinRT的，封装了COM接口的引用计数、HRESULT转换、IAsyncInfo异步。
--
FROM 223.72.62.*
以前qt mfc 自己从头搞，是因为stl不成熟
现在c++都要23了，stl也几十年了， 为啥还要自己搞一套？
【 在 essentialc 的大作中提到: 】
: UWP不行了可是WINRT没说弃用吧？有些特性没有win32 API只有WINRT API，
--
FROM 223.72.62.*
我不太了解， winrt包装的window功能，不管是基于win32，还是基于os内核，原本都是c/c++吧
现在要提供一个c++的接口，为啥还要再用com包一下？
最好的做法，是c++提供原生c++接口， 再包个com给c#?
【 在 z16166 的大作中提到: 】
: WinRT(windows runtime)是用COM实现的，多种语言如c#、c++等都能调用。
: C++/WinRT是方便C++来调用WinRT的，封装了COM接口的引用计数、HRESULT转换、IAsyncInfo异步。
--
FROM 223.72.62.*
但是微软可能故意把C++带歪，因为C/C++是非windows平台的主要开发工具，把C++带歪了，
就会影响非windows平台的发展，让windows占有更多市场。
有没有这个可能？
【 在 mopo 的大作中提到: 】
: 标准委员会虽然很多大佬就是微软的，但考虑到开放性，效率一直很低，但是windows是要赚钱的，不可能一直按照委员会的步点来规划技术路线
: 其他的类似c++魔改方案也是类似，stl虽然nb，但是一些常用功能都不支持，自己造轮子也是逼不得已，就算是java这么成熟的官方库，也满足不了很多细化需求，也有大量的轮子
--
FROM 223.72.91.*
微软推wsl，是想把linux开发者留在windows平台，希望linux只是服务器，不要作为工作和开发平台。
对微软来说，windows，桌面平台是他的生存基础。他绝不希望为linux提供高效好用的桌面开发工具。
linux桌面应用软件丰富了，自然就会吸引一部分人放弃windows
这对微软来说是战略高度的。
【 在 mopo 的大作中提到: 】
: 微软内部也不是铁板一块，mfc、mangaged c++、.net不知道多少套了，最近开源的k-v存储也是基于.net的，最终目的当然是想把开发者绑定在windows平台，但云服务又相对开放，并不排斥linux系统，单机甚至还推出了wsl方便linux开发者，这在以前是不可想象的，就是在封闭和开放之间找平衡吧
:
--
FROM 223.72.91.*