Qt on Windows - What is your experience?
Hi, I am currently developing my application on Windows, Linux and Mac OS X. On Windows, I use MinGW 4.4 which is shipped with the Qt SDK. Two main reasons to this really: 1) it’s very easy to set up my Qt environment on Windows, and 2) I use only one compiler across the different platforms that I want to support (thus avoiding any possible issues between MSVC and GCC).
Still, I use (the binaries of) a third-party library which, on Windows, is built using either MSVC or the latest MinGW (i.e. not the one shipped with the Qt SDK). I use the latter, but this is causing me problems.
So, I was wondering what you guys’ experience is with regards to Qt on Windows? Should I (try to) stick to GCC or would it be in my interest (?!) to switch to MSVC?
PS: according to http://doc.qt.nokia.com/latest/supported-platforms.html [doc.qt.nokia.com], it would seem that Qt’s Windows support is primarily on MSVC, even though I would imagine that GCC support on Windows is considered inherent because of its use on Linux and Mac OS X?
I also develop cross-platform, but mainly on Windows.
I use the SDK, mainly because of ease of setup, and I have come to like some text editor features in Creator that seem to be missing in Visual Studio. And it supports Qt perfectly, of course.
On the other hand, compiling and debugging growing projects is starting to become a real pain with MinGW. The application takes ages to compile and link (about 10 sec just waiting for MinGW to figure out the executable is still up-to-date, and that’s only for a mid-sized project), and debugging is also slow in many respects (startup, watches), and has severe limitation (template classes!)
As I work on larger and larger project, I might end up using Visual Studio yet.
I don’t have any experience with MSVC, but I would agree that compiling with GCC on Windows is much slower than on Linux (and Mac OS X for that matter). Still, and as much as possible, I would like my setup to be easily reproducible and I would like to keep conflicts between compilers/platforms to a minimum, hence I am currently using GCC on Windows. However, I am open minded, so should there be good arguments in favour of switching to MSVC, then I will eat the bullet and do it (even though I feel like it might a bit of work).
True, but this is already the case in some way with using GCC on different platforms, especially since it’s version 4.4.0 on Windows while a much newer version on Linux for example. So, there have been cases where I would get no warning on Windows and some on Linux.
Anyway, I would be interested to know what people’s experience of MSVC compared to GCC has been on Windows. Especially if, for whatever reason, they have to support both compilers.
Thanks Andre. I have had a quick look at Qt + MSVC2010 using /Wall because I don’t want warnings, but I ended up getting more than a thousand of them (!!). Then, I found out (here: http://stackoverflow.com/questions/4001736/what-with-the-thousands-of-warnings-in-standard-headers-in-msvc-wall [stackoverflow.com]) that /W4 ought to be preferred to /Wall. Yet, I still get a few Qt-specific warnings (e.g. http://stackoverflow.com/questions/2742514/qt-warning-level-suggestion [stackoverflow.com]). I was therefore wondering what you were doing with regards to warnings generated by MSVC2010 (or whatever version you use)? Do you do what is mentioned in the last link I gave above?
I’m primarily using GCC 4.7 on Windows without any problems so far. The MinGW64 [mingw-w64.sourceforge.net] project provides up-to-date distributions of GCC 4.6.x and GCC 4.7 for i686 and x86_64 (I would recommend the personal build of rubenvb).
The reasons for GCC are easily explained:
- A homogenous build environment on all supported platforms, from Linux to Mac OS X to Windows to Android or any other mobile platforms.
- The installation is as simple as extracting an archive, which leaves me with a complete, uninstrusive and independent build environment that I can freely move around. One could even integrate the build environemnt into the repository if neccessary.
- It is free in terms of cost, the license and most importantly distribution. There is no problem in distributing the build environment along with the source code of the application. Although MSVC is free for commercial applications, I still have to force the foreign developer to download and install either Visual Studio or the Windows SDK.
- And finally for me the most important reason, active development. It becomes more and more apparent that Microsoft silently moves away from C++ and (at least for now) focuses on absurdities like Managed C++ or C++/CLI. The improvments for MSVC2011/12 over MSVC2010 are moderate, C++11 support is a downright joke, especially when considering that C++11 in MSVC2010 was mediocre at best.
MSVC does result in faster code on the whole though.
If latest tests [translate.googleusercontent.com] are to be believed the difference is de facto negligible. If you are looking for performance Intel is the way to go anyway.
Thanks for this Lukas. A few questions/comments if you don’t mind:
- I am wondering why the Qt guys are not supporting a more up-to-date version of MinGW. Is there any particular reason? In fact, the version they ship with the Qt SDK is patched, but maybe there would be no need to patch if they were to use a more recent version…?
- I imagine you have to build Qt from scratch and can’t just use the MinGW version of the Qt SDK out of the box?
- Something I noticed in my very early tests with MSVC is that compilation is much faster and the size of the files much smaller. On the other hand, to set up a Qt/MSVC environment is rather time consuming compared to Qt/MinGW. # Regarding MinGW64, what is the difference between the different builds?
MSVC does result in faster code on the whole though.If latest tests [translate.googleusercontent.com] are to be believed the difference is de facto negligible. If you are looking for performance Intel is the way to go anyway.
For the code I was working at at the time, it made quite a difference. I don’t care about a generic comparison, I care about the code I work on. To know what works best for you, you’ll have to test for your own situation.
We’ve switched from MSVC to MinGW recently on our commercial project due to the much more easier setup of the application at the users’ sites. It is very hard to deploy an MSVC based application with the runtime dependencies (vcredist stuff) without administrator rights on the deployment box. Actually, I never managed to make this work. With MinGW, on the other hand, that’s a no brainer, just copy all needed DLLs into the application directory and you’re done.
SDK is patched, but maybe there would be no need to patch if they were to use a more recent version…?# I am wondering why the Qt guys are not supporting a more up-to-date version of MinGW. Is there any particular reason? In fact, the version they ship with the Qt
Honestly, I don’t know (but I heard the same rumors) – but I understand that switching the default toolset does in fact require some work (mostly testing) and that almost everyone is now primarly focusing on Qt 5, which (so I guess) will bring GCC 4.6.2 and/or GCC 4.7 (which are the recommended GCC versions for Qt5 alpha).
SDK out of the box?# I imagine you have to build Qt from scratch and can’t just use the MinGW version of the Qt
MSVC is that compilation is much faster and the size of the files much smaller. On the other hand, to set up a Qt/MSVC environment is rather time consuming compared to Qt/MinGW.# Something I noticed in my very early tests with
Subjectively I would say GCC (or better MinGW) might be slower, but not much slower (although I haven’t verified this). The same goes for file size, which even doesn’t bother in (m)any of my use cases.
- MSVC MinGW 4.4 MinGW 4.7
- QtCore4.dll 2.498 KB 2.777 KB 3.035 KB
- QtGui4.dll 8.366 KB 9.898 KB 11.028 KB
# Regarding MinGW64, what is the difference between the different builds?
The basically differ in the GCC version used, the amount of SDK headers included, the exception model, or whether they are prefixed or not (×86_64-w64-mingw32-gcc.exe vs. gcc.exe). I’ve found the personal build of rubenvb the most recent and feature complete so far plus it is non-prefixed (and so works as a drop-in replacement for the MinGW delivered with the SDK).