which is better, MinGW64 or MSVC 2019 64bit for general use applications.
-
I'm making a 64bit based application for my small commercial, but it's better to use MinGW64 or MSVC2019 64 bit, what are the advantages and disadvantages of these two? I'm using dynamic not static applications.
When I use MSVC on several laptops/computers, it requires vc_redistx64.
-
@Blackzero
Although I am a fan of open source applications, and for "general use" these toolchains are probably equally suitable, I would have to say that if I had to pick one to work with for Windows applications it would have to be MSVC. I assume it is much more widely used than MinGW. It has a wider set of tools. Its IDE is superior (though if you are using Qt/Creator this may not be an issue). It has wider interoperability with certain third-party products. Even in Qt certain platform-specific modules can only be compiled with MSVC not MinGW: for example, if you want Bluetooth or WebEngine support under Windows you have to be using MSVC, they are not available for MinGW.One thing in favour of MinGW is if you are developing cross-platform to include Linux, where it is the equivalent of the gcc you would use there.
Especially when using Qt's platform/compiler abstraction layer you should not be writing compiler-specific code. You could start with the MinGW supplied with Qt (instead of installing MSVC yourself) and at a later date switch to MSVC relatively painlessly.
Those are my thoughts.
-
@JonB said in which is better, MinGW64 or MSVC 2019 64bit for general use applications.:
@Blackzero
Although I am a fan of open source applications, and for "general use" these toolchains are probably equally suitable, I would have to say that if I had to pick one to work with for Windows applications it would have to be MSVC. I assume it is much more widely used than MinGW. It has a wider set of tools. Its IDE is superior (though if you are using Qt/Creator this may not be an issue). It has wider interoperability with certain third-party products. Even in Qt certain platform-specific modules can only be compiled with MSVC not MinGW: for example, if you want Bluetooth or WebEngine support under Windows you have to be using MSVC, they are not available for MinGW.One thing in favour of MinGW is if you are developing cross-platform to include Linux, where it is the equivalent of the gcc you would use there.
Especially when using Qt's platform/compiler abstraction layer you should not be writing compiler-specific code. You could start with the MinGW supplied with Qt (instead of installing MSVC yourself) and at a later date switch to MSVC relatively painlessly.
Those are my thoughts.
yes so far I have been using MSVC2019 but most laptops require vc_redist so that the application does not error, I want to make it static so that it does not require vc_redist but the price is quite even, if I use open source static it is not possible because my goal is for my own small commercial.
-
I have personally always been using MSVC on Windows and would always pick this as a compiler. The Visual Studio debugger is a lot better than the one built in to Qt Creator (debugging in Qt Creator can be terribly slow on Windows taking several minutes for just a single step).
vc_redist can be a little bit annoying. However, when you are using an installer for your software this can be included as a dependency and will be fine.
@Blackzero said in which is better, MinGW64 or MSVC 2019 64bit for general use applications.:
if I use open source static it is not possible because my goal is for my own small commercial.
This is not entirely true. In order to use open source static you need to compile Qt yourself. This is doable. The LGPL requires for the user to be able to relink with a different Qt version. As long as you are willing to provide your objects files (maybe already linked into a static library) together with an explanation of how to link to static Qt libraries, this is also feasible. Even though the LGPL provides these rights to the user, in general it is highly unlikely that anyone will make use of this right. This might be a risk you are willing to take (i.e. the risk that you never have to effectively provide a way for a user to relink with a different static Qt version because noone will ever make use of this right). (I'm not a lawyer; this is not legal advice.)
