11

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?

ndbd
  • 349
  • 1
  • 3
  • 8
  • 4
    I would recommend to do it just for the experience. But I might be biased as I love C#/WPF. – Euphoric Apr 27 '18 at 11:13
  • 3
    And Joel's "nevery rewrite from scratch" meme is mostly about corporate "enterprise" software. Not about small hobby projects. – Euphoric Apr 27 '18 at 11:16
  • What about Xamarin.Forms? – Sentinel Apr 27 '18 at 13:32
  • I personnaly found the learning curve to be kind of steep with WPF. At least if you want to style everything and such. But I really liked working with that stack and it was really powerfull – Rémi Apr 27 '18 at 14:35
  • 2
    If you rewrite it, why don't you make it browser-based? HTML/CSS is much less of a headache for the gui than WPF, and the backend can still be in C# (maybe using asp.net core or nancy.fx). – Wilbert Apr 27 '18 at 14:39
  • @Wilbert: The kind of application is just not suitable to be browser-based, neither for hosting (i.e. cloud based web-app), nor for running locally in a browser - data intensive. Also, in the hosting scenario _I_ would be paying a lot for my hobby for the nec. CPU power, whereas in the application case, the user is utilizing his local CPU.... – ndbd Apr 27 '18 at 14:46
  • 3
    @Wilbert "HTML/CSS is much less of a headache for the gui than WPF" I tactfully dissagree. HTML/CSS + JS is huge mess that was never intended for application UI. – Euphoric Apr 30 '18 at 06:43
  • @Euphoric JS potentially, yes. But with Typescript and a reasonable library, you can build richer and _much_ better performing UIs with web tech than WPF, which has stagnated in Limbo for way too long already and still uses DirectX9. And with WebGL support, you get better, more stable and more widely usable support even for 3d than anything WPF could offer. – Wilbert Apr 30 '18 at 06:53
  • @Wilbert "reasonable library". Sure, immortality is possible when you have unicorn blood. /s Really. Show me "reasonable library" for browser UI. – Euphoric Apr 30 '18 at 07:43
  • @Euphoric We are digressing, but I would think Angular.io (aka Angular5) fits the bill. It's even conceptually close to MVVM with its components, just less of a hassle than WPF. – Wilbert Apr 30 '18 at 10:09
  • What is your application doing? Is the code free software (e.g. on [github](http://github.com/))? Where? Notice that C#/WPF might not be *easily* usable on Linux or MacOSX (but Qt applications are) – Basile Starynkevitch May 01 '18 at 10:39
  • @BasileStarynkevitch : Yes, free (as in open source) software, data processing and visualization software, e.g. custom widgets to draw things on screen (albeit so far no 3D, just 2D), searching, indexing and processing large binary data-files on disk, and inter-process communicatin via pipes. Network functionality might be added later... – ndbd May 03 '18 at 09:47
  • Qt is horrid in my experience. It seems to date back to an MFC style of programming with deep inheritance and legacy-style ways of dealing with memory, not to mention the MOC. I never tried WPF but I've tried many alternatives to Qt, and the grass was truly always greener on the other side.I truly loathe Qt so much if people will forgive me for it. My team adopted it in the mid-2000s for a project and it was such a PITA with respect to everything from making our build systems use the MOC to customizing the GUI to match the way our designer wanted it to look and feel. –  Nov 02 '20 at 11:24
  • I was one of those weirdos on the team who wanted to at least wrap Qt and design our interfaces based on the very precise design requirements we had, and what our designer wanted, which was the most miniature subset of what Qt provided. Team voted against that and we ended up with so much pain, user-end inconsistencies from the way one dev used a widget from another, etc. etc. etc. Most of all, it made our designer infuriated as we constantly had to explain to him that Qt, at least in vanilla form, wasn't designed to do the things he wanted. –  Nov 02 '20 at 11:28

5 Answers5

12

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.

ndbd
  • 349
  • 1
  • 3
  • 8
  • Well, one can do memory leaks in Java; there is no reason to be free of it. – Soleil Mar 14 '21 at 20:01
  • 1
    Maybe one _can_ theoretically create memory leaks in Java, but it's actually quite difficult to do (i.e. deliberately ignore try/catch/finally). This is similar to C# or other managed languages. In C++ it's pretty easy though :-) – ndbd Mar 15 '21 at 12:23
  • Doesn't smartpointers rid memory leaks? – Luke101 Feb 05 '23 at 06:06
  • Qt has a different memory-model dating back into the 90s; predating smartpointers. I found mixing C++ smartpointers with Qt programming cumbersome. Java together with a Java-based GUI framework is vastly more productive from my perspective. – ndbd May 11 '23 at 11:20
11

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.

17 of 26
  • 4,818
  • 1
  • 21
  • 25
  • 13
    Qt is in a completely different league than MFC. Comparing those two is not useful – besc Apr 27 '18 at 15:19
  • 1
    From my own experience, even from just console applications, I moved from Python to Qt, because I found that Qt was vastly faster to develop and easier to understand in every single way. I would never say that with just C++. The takeaway being that comparing Qt and C++ as the same, is folly. – Anon May 19 '18 at 04:27
11

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.

James Picone
  • 257
  • 1
  • 5
  • 3
    Did you last use WPF with .NET 3.0/3.5 or what? It's pretty mature now. – MetalMikester May 01 '18 at 11:55
  • 4
    @MetalMikester Nope, this was recent. And it's not just me; other developers working here have had similar experiences. As far as I can tell everyone on the internet lives in a bizarre alternate universe where WPF works. I'm dead serious about the lack of documentation, by the way. Never found a decent source; possibly because Microsoft are notoriously bad at having their documentation google-able. – James Picone May 02 '18 at 08:19
  • 2
    Don't know what to say. I used it from 2008 up until last year. It was a bit challenging the first couple of years, but after that we were just cruising along and didn't find it hard to get the help we needed on the Internet. – MetalMikester May 02 '18 at 11:29
  • I am accepting this answer, @JamesPicone so far is the only answer where someone provided insight having experience in _both_ (Qt and WPF) frameworks. – ndbd May 03 '18 at 09:42
  • 11
    Raw win 32 over WPF? Are you kidding? Btw, you're lying about the documentation. There are tons of good sources/tutorials about WPF. – Xam May 03 '18 at 13:58
  • 1
    @Xam I am absolutely not kidding. Win32 is a hassle, yes. But you can build abstractions over it and maybe improve matters and have some idea of what's going on. My experience with WPF, to date, has been bizarre magic doing something weird because the abstraction doesn't quite cover the thing it's abstracting over properly. It's impossible to understand what's going on because there are so many layers, and building a mental model is hard because many of the layers do very, very strange things. Dependency properties sidestepping property setters/getters is a good example. – James Picone May 04 '18 at 01:43
  • @Xam on the topic documentation, I can only present what I've personally found - there's a lot of stuff out there, and the vast majority of it is cargo-cult, most of which is either wrong or terribly designed. And it's very hard, as somebody new to WPF, to figure out which ones shouldn't be trusted. Microsoft does have official documentation, but it's got all the usual Microsoft doc issues - it describes what APIs do at a direct level, but doesn't explain why you would want to use it, and relies heavily on terminology you haven't learned yet because you're reading the documentation. – James Picone May 04 '18 at 01:46
  • @ndbd To be fair I probably have a somewhat unusual PoV here. I have seen people hatin' on WPF and XAML online (http://paulstovell.com/blog/six-years-of-wpf for example), but it's certainly not a common viewpoint. I'm not much of a fan of C# either. Maybe WPF is difficult to learn, so first-timers have a tendency to write horrible unmaintainable messes, and I haven't gotten past that point yet? I don't know. – James Picone May 04 '18 at 01:56
  • I have no QT experience, but I programmed a little in C++. i find c# to be much easier to use than c++. In terms of UI, xaml (used by wpf as markup language) has a very steep learning curve, especially when you wanna go for the MVVM pattern. MVVM is recommended for every app that is more than 500 lines of code to create cleaner sepearations between UI, UI handling and buisness logic/model data. The problem with xaml is, that it is very verbose and for some simple UI problems you may need quite some code and experience to get it to work with wpf MVVM. – Welcor Jun 11 '20 at 09:13
  • This answer is only founded on poor personal experience with WPF and lack of understanding of the framework, it should not influence choices of the users if not substantiated with valid experience in matter. Check the other answers below to see a totally different picture. – powernemo Aug 28 '20 at 14:23
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.

Soleil
  • 143
  • 5
3

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.

Soleil
  • 143
  • 5
Edgar
  • 293
  • 1
  • 2
  • 10