Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve C++/WinRT productivity versus C++/CX, Qt/C++, C++ Builder #551

Closed
pjmlp opened this issue Mar 11, 2020 · 1 comment
Closed

Improve C++/WinRT productivity versus C++/CX, Qt/C++, C++ Builder #551

pjmlp opened this issue Mar 11, 2020 · 1 comment

Comments

@pjmlp
Copy link

pjmlp commented Mar 11, 2020

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.

@kennykerr
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants