- 主题:C++/WinRT为什么搞一套自己的基础类型，不适用stl？
既然要使用标准c++了，为什么还要自己搞一套
增加程序员的转换负担？
性能不是问题啊，都用uwp做ui了，就不在乎winrt自己转换的开销了
--
FROM 223.72.62.*
巨硬的这个技术栈原本就是有来给 c# 打下手，把 c++ 的软件包装成 dotnot 可以使用的 dll. 弄成什么样子都是巨硬说了算啊。
之前在 Qt 里面看到相关的代码，是 Qt 想在 UWP 里面调用一些 API 获得代理、CA 证书列表之类的。但其实 Qt 没有必要做这些。因为，
巨硬已经放弃 UWP 了。以后大家还是继续用 win32api 开发 Windows 应用吧。
【 在 finlab 的大作中提到: 】
: 既然要使用标准c++了，为什么还要自己搞一套
: 增加程序员的转换负担？
: 性能不是问题啊，都用uwp做ui了，就不在乎winrt自己转换的开销了
: ...................
--
FROM 183.253.146.*
WinRT(windows runtime)是用COM实现的，多种语言如c#、c++等都能调用。
C++/WinRT是方便C++来调用WinRT的，封装了COM接口的引用计数、HRESULT转换、IAsyncInfo异步。
--
FROM 123.119.160.*
com性能很低啊， 我还以为是直接用c++封装的win32接口
如果是com的话，估计还是用com封装的dotnet
【 在 z16166 的大作中提到: 】
: WinRT(windows runtime)是用COM实现的，多种语言如c#、c++等都能调用。
: C++/WinRT是方便C++来调用WinRT的，封装了COM接口的引用计数、HRESULT转换、IAsyncInfo异步。
--
FROM 223.72.62.*
老的windows api是纯c接口的，应该是MS不想用这套了（或因为纯c的api给c#、uwp等调用起来也麻烦），就搞了一系列COM接口的api，这些COM接口是有配套的metadata的（叫.winmd)），方便自动生成，感觉类似RPC接口的midl描述文件。
【 在 finlab 的大作中提到: 】
: com性能很低啊， 我还以为是直接用c++封装的win32接口
: 如果是com的话，估计还是用com封装的dotnet
:
--
FROM 123.119.160.*
COM 为啥性能低？COM 相对于普通的C++代码的效率对比，只不过是虚函数和和普通函数的区别而已。而且通常大家都提前把各个函数的地址存下来。调用的时候也就不需要查表了。
【 在 finlab 的大作中提到: 】
: com性能很低啊， 我还以为是直接用c++封装的win32接口
: 如果是com的话，估计还是用com封装的dotnet
:
--
FROM 123.113.230.*
UWP不行了可是WINRT没说弃用吧？有些特性没有win32 API只有WINRT API，
--
FROM 1.192.217.*
以前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.*
winRT实现的COM组件自带了一些cpp的设计模式，比如crtp，还有一些COM注册标准化；可以方便减少一些代码的手动输入，语法说了和cpp 17兼容，还没发现差异很大的地方
--
FROM 1.192.217.*