You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am now trying to port an old C++/CX application into C++/Winrt and I keep being disappointed by the producivity drop in name of ISO C++17 above all.
I do concede it was an amazing achievement to provide a C++ language projection for UWP, but apparently keeping C++/CX productivity wasn't a goal.
With C++/CX I though Visual C++ had finally justified the Visual part of the name, catching up to what C++ developers have been able to enjoy with Qt and C++ Builder since early 2000's, instead I have now to write MDIL files by hand, integrating perfectly working libraries like Win2D leads to StackOverflow workarounds to deal with lacking tooling, there are C++/CX XAML editing features still lacking, because now we have to wait for ISO C++23 to hopefully provide those features for C++/Winrt to achieve parity with C++/CX tooling.
Just voicing my usability complaints already expressed on WinUI 3.0 roadmap tooling issues, and while C++ Builder might not be a viable alternative for many C++ developers, Qt surely is, with the added benefit of cross platform support.
So please take into consideration that not every C++/CX user was unhappy with it, and C++/Winrt doesn't feel that great to us, when we get asked to deal with low level stuff like manually writing MDIL files (even if 3.0 is a big improvement), winrt namespace interop types, east const advocacy, implementation patterns for some COM/WInRT interop, lack of Visual Studio templates (3 bare bones ones, really?).
It even makes Visual Studio's MFC tooling feel modern, and maybe it might not have the desired effect to bring into UWP C++ developers outside Windows and Office teams, unless we are being paid to put with it.
While it may look like a rant, I actually would like Visual C++ to feel more like C++ Builder and less like UNIX C++, but I guess we probably aren't the target audience for C++/Winrt.
The text was updated successfully, but these errors were encountered:
Thanks for the feedback! I certainly agree that productivity is a problem. While I'm not fond of C++/CX, Visual Studio and Xaml continues to provide superior tooling support for it and C++/WinRT as the standard C++ alternative suffers from a lack of support from the IDE. I do however believe that standard C++ is the long-term solution, but more work needs to be done in three areas:
Visual Studio needs to add deep support for C++/WinRT
Xaml needs to add support for C++/WinRT without requiring IDL
C++/WinRT needs to support the forthcoming C++ reflection and injection features
I continue to advance C++/WinRT as the language evolves, but please keep pushing for improved Visual Studio and Xaml support by letting the Visual Studio and Xaml teams know that this matters.
I am now trying to port an old C++/CX application into C++/Winrt and I keep being disappointed by the producivity drop in name of ISO C++17 above all.
I do concede it was an amazing achievement to provide a C++ language projection for UWP, but apparently keeping C++/CX productivity wasn't a goal.
With C++/CX I though Visual C++ had finally justified the Visual part of the name, catching up to what C++ developers have been able to enjoy with Qt and C++ Builder since early 2000's, instead I have now to write MDIL files by hand, integrating perfectly working libraries like Win2D leads to StackOverflow workarounds to deal with lacking tooling, there are C++/CX XAML editing features still lacking, because now we have to wait for ISO C++23 to hopefully provide those features for C++/Winrt to achieve parity with C++/CX tooling.
Just voicing my usability complaints already expressed on WinUI 3.0 roadmap tooling issues, and while C++ Builder might not be a viable alternative for many C++ developers, Qt surely is, with the added benefit of cross platform support.
So please take into consideration that not every C++/CX user was unhappy with it, and C++/Winrt doesn't feel that great to us, when we get asked to deal with low level stuff like manually writing MDIL files (even if 3.0 is a big improvement), winrt namespace interop types, east const advocacy, implementation patterns for some COM/WInRT interop, lack of Visual Studio templates (3 bare bones ones, really?).
It even makes Visual Studio's MFC tooling feel modern, and maybe it might not have the desired effect to bring into UWP C++ developers outside Windows and Office teams, unless we are being paid to put with it.
While it may look like a rant, I actually would like Visual C++ to feel more like C++ Builder and less like UNIX C++, but I guess we probably aren't the target audience for C++/Winrt.
The text was updated successfully, but these errors were encountered: