Moving from Qt/C++ to C#/WPF - Productivity Gain?

Question

I created a small Desktop application (approx 15000 lines of code, so not that large) written in C++/Qt. This is non-commerical, just a hobby project and I am coding on my free time.

The larger the application gets, I find it more and more tedious to write C++, and adding new features takes a lot of time.

• I find it especially hard to manually manage memory - even with smart pointers, I have to often think of ownership, on how to pass objects efficiently.
• Compile times are slow, as there is no real-time compilation
• Even modern C++ syntax is often somewhat cryptic and full of type annotations and somewhat tedious to write
• My application is based on several custom Qt Widgets, which makes using the Designer difficult. This results in a lot of time spent creating simple dialogs and interfaces manually by code.

Cross-Platform is interesting, but the majority of my users are on Windows anyway.

These are all reasons that make me think of moving to C#/WPF.

On the other hand, there is the strong "nevery rewrite from scratch" meme (cf. Joel Spoesky's famous blog entry), and I fear I might suffer from the "grass is always greener of the other side" syndrome.

What is your experience with projects converted from C++/Qt to C#/WPF? What perceived productivity gain did you yield after converting and writing pure C#? How tedious was the rewrite process? Is it diffcult to move from Qt's signal/slot thinking to the MVVM approach? What's learning curve for WPF like?

Answer 1

I have significant experience with C++ UI development, mostly in Qt but also including wxWidgets and raw win32. I've also done some C# UI development in WPF.

I would strongly recommend literally any of the UI technologies I've used - including raw win32 - over C#/WPF. In my experience it's poorly documented, incredibly slow, and all of its abstractions leak like a sieve.

Try searching around for people's solutions to problems like "Make a variant of a standard control with slightly different behaviour" or how to debug issues in XAML declarations. Should give you some idea of what to expect.

I don't personally have any experience with WinForms, but I've seen people suggest it as an alternative; maybe try that if you don't want to use C++ any more.

Answer 2

Two years later, I'll add an answer myself. This purely reflects my own experience, but might help others in the same situation.

Due to cross-platform availability, I didn't move to C#/WPF but rather to JavaFX. I have approx. finished porting 40% of the whole the application and so far I heavily regret that I didn't port the whole thing way earlier. Or in other words: I am magnitudes more productive, and coding is fun again. There are two things I'd like to distinguish:

1. JavaFX vs QT as a GUI framework. First, I think that GUI frameworks always are a bit annoying to program for; there is always a small thing that doesn't really fit and doesn't really look the way you intend it to be. JavaFX is really straight-forward though and as doing everything in code as opposed to using FXML is a perfectly valid approach (compared to say WPF where XAML is a must) you don't jave to learn another language. When comparing JavaFX to QT Widgets I have to say though that QT offers more out-of the box widgets, whereas in JavaFX you sometimes have to "roll your own".

2. C++ compared to Java as a language: No more memory leaks, full stack traces, faster compile times, Maven and Maven Central - need I say more? During porting I actually found several bugs in the old application logic core precisely due to better tooling. One perculiarity of my old application logic was that I needed to quickly allocate and destroy lots of small objects, something where I had to write my own allocator in C++ - whereas Java shines here out of the box. One issue is here that Qt datastructures often come with "hidden" mallocs, as they behave different ("implicit sharing") than modern C++. All in all, the logic core is actually faster now... The switch from C++ to a managed language is really where the productivity gain happens.

Again, this reflects my own personal experience, but I really regret not giving up on C++ way earlier and wasting so much time into hourless debugging and leak-hunting sessions.

Answer 3

I don't have any experience with QT, but I spent over a decade working with C++ and MFC. I now have almost a decade working with C# and WPF.

I find that I am an order of magnitude more productive in C#/WPF than I ever was in C++/MFC.

As a language, I find myself being far more productive in C# than I ever was in C++. Part of this is not having to worry about memory management most of the time (frees up your brainpower to think about other things). Part of that is the fact that C# syntax is much cleaner than C++ and has some really nice features (although C++ is getting better with the newer specifications).

WPF is hands down the most productive UI framework I've ever worked with. XAML is declarative (like HTML) but typesafe (like C#). In my opinion, this is the best of both worlds for creating user interfaces. Databinding is a very powerful feature that makes it easy to link UI controls to the data that they manipulate.

Answer 4

I've been shared between WPF, Qt, JavaFX years ago, and chose WPF/c#/XAML/MVVM and find it very fast to develop, excellent to maintain, powerful in terms of possibilities and performance; it relies on DirectX and is not crossplatform for this reason, but Avalonia is a cross-platform alternative to WPF.

I also can inject easily in WPF apps: native c, c++, cuda, DirectX12 and DX12-cuda widgets, for high end colors, dynamic, high performance and low latency graphics and HPC.

The WPF license is also more interesting since it's not GPL/related and always free of charge; and the support on stackoverflow and with Microsoft is really great.

Answer 5

I learned C#, WPF, MVVM, Entity Framework and probably some more technologies from scratch after I programmed for years with VB6, VBA, SQL and others.

It was a steep learning curve and it took a long time. But I am happy that I did it. Because C# and WPF are wonderful technologies, especially combined with MVVM.

Many years ago I wrote a program in VB6 to play audio and video files on multiple screens with an easy to use GUI but still lots of features. Now I developed something similar but better from scratch with above technologies. It takes time but it's fun to do it and it's fun to see all the new options with animations, etc.

My advice: if you do this "only" to make money then it's likely that all the hours you would spend on learning the new technologies will never get paid. It is a lot of work to learn it all and a lot more work to use it efficiently (that's where I am in the moment).

If you like programming and if you like to see how much easier things work with new technologies then I recommend that you write your program from scratch. But be prepared to write and maybe rewrite it. In my case I started with the program with C# and WPF and some time later it got difficult and then I learned about MVVM and I changed everything according to that concept. It took a long time. I am still not finished (mostly because of limited time) but I like programming and I like to see my progress. I will never be able to charge for all the time it cost me but I enjoy it and it will give me more options for the future. This is why I do it.