GCC worth using on Windows to replace MSVC?

Question

I currently develop in C++ on Windows, using Visual Studio 2010. After the official announcement of C++11, I have begun to use some of its features that are already available in MSVC. But, as expected, the great majority of the new changes are not supported.

I thought maybe the upcoming version of Visual Studio would add these new features. However, after reading this it looks like very little is going to change.

And so, I'm curious about the feasibility of using GCC on Windows rather than MSVC, as it appears to support the great majority of C++11 already. As far as I can tell, this would mean using MinGW (I haven't seen any other native Windows versions of GCC). But I have questions about whether this would be worth trying:

• Can it be used as a drop-in replacement for cl.exe, or would it involve a lot of hacks and compatibility issues to get Visual Studio to use a different compiler?
• The main selling point for Visual Studio, in my opinion, is it's debugger. Is that still usable if you use a different compiler?
• Since GCC comes from the *nix world, and isn't native to Windows, are there code quality issues with creating native Windows applications, versus using the native MSVC compiler? (If it matters: most of my projects are games.)
• In other words, will the quality of my compiled exe's suffer from using a non-Windows-native compiler?

Solution 1

MSVC has the huge advantage of coming with an IDE that has no equals under Windows, including debugger support.

The probably best alternative for MinGW would be Code::Blocks, but there are worlds in between, especially regarding code completion and the debugger.

Also, MSVC lets you use some proprietary Microsoft stuff (MFC, ATL, and possibly others) that MinGW has no support for, and makes using GDI+ and DirectX easier and more straightforward (though it is possible to do both with MinGW).

Cygwin, as mentioned in another post, will have extra dependencies and possible license issues (the dependency is GPL, so your programs must be, too). MinGW does not have any such dependency or issue.

MinGW also compiles significantly slower than MSVC (though precompiled headers help a little).

Despite all that, GCC/MinGW is an entirely reliable quality compiler, which in my opinion outperforms any to date available version of MSVC in terms of quality of generated code.
This is somewhat less pronounced with the most recent versions of MSVC, but still visible. Especially for anything related to SSE, intrinsics, and inline assembly, GCC has been totally anihilating MSVC ever since (though they're slowly catching up).

Standards compliance is a lot better in GCC too, which can be a double-edged sword (because it can mean that some of your code won't compile on the more conforming compiler!), as is C++11 support.

MinGW optionally also supports DW2 exceptions, which are totally incompatible with the "normal" flavour and take more space in the executable, but on the positive side are "practically zero cost" in runtime.

Solution 2

I want to add some information because the field may have changed since the question was asked.

The main problem for switching away from MSVC was the lack of a good IDE that flawlessly integrates with MinGW . Visual Studio is a very powerful tool and was the only player on Windows for quite some time. However, Jetbrains released a preview version of their new C++ IDE CLion some days ago.

The main benefit comes when working on cross platform applications. In this case, a GCC based tool chain can make life much easier. Moreover, CLion narrowly integrates with CMake, which is also a big plus compared to Visual Studio. Therefore, in my opinion, it is worth to consider switching to MinGW now.

Solution 3

GCC's C++11 support is quite phenomenal (and quite up to par with standards conformance, now that <regex> has been implemented).

If you replace your compiler, you'll need to make sure every dependency can be built with that new compiler. They're not made to be substitutable plugins (although Clang is working on becoming that way).

GCC is a fine compiler, and can produce code that has pretty much the same performance, if not better, than MSVC. It is missing some low-level Windows-specific features though.

Apart from this, to answer your questions:

1. To get VS to use GCC as a compiler, you'd pretty much need to turn to makefiles or custom build steps all the way. You'd be much better off compiling from the commandline and using CMake or something similar.
2. You cannot use the VS debugger for GCC code. GCC outputs GDB compatible debug information, and the VS debug format is proprietary, so nothing will change in that area anytime soon.
3. Code quality is just as good as you'd want it. See above.
4. No, the quality of your code will actually increase, as GCC will point out several assumed standard extensions MSVC would hide from you. All self-respecting open source projects can be compiled with GCC.

Solution 4

I my humble opinion, it's depends how someone started to code in the first place. I've been using g++ and gcc for more than 20 years now but the reason why i keep using gcc is mainly for licensing reasons. Although i like it too when i don't have a bunch of runtime dependencies or dll's to bundle with my stuff since i came from the DOS era, i still like my stuff small and fast. gcc for windows comes with standard win32 libraries and common control but i had to develop my own win32 controls for stuff that might require mcf shit to work properly or just to look nicer.

Although gcc might have strong support over internet, when it comes to win32 stuff, many rely on mcf and vc proprietary stuff so again, one may have to work his own issues around and be creative when difficulty arises.

I think it's all about needs and circumstances. If you are just a hobbyist coders and have the time for researches, creating you own libs and stuff but you want a solid compiler that's around since the late 80's and free, gcc sound perfect for the job.

But in the industry visual studio is a must if you want to be competitive and stay in the race. Many hardware manufacturers would prefer bundling visual studio compatible libraries for they hardware over some opensource gnu stuff.

That's my two cents.

Solution 5

To be honest, C++ should be handled with MS Visual Studio. If you want to make cross-platform or Unix apps, use GCC. GCC works and can be used with any IDE other than Visual Studio. Even Visual Studio Code can use GCC. Code::Blocks, Eclipse IDE for C/C++ developers, CLion, Notepad++ and even the good ol' tool we've always known, Notepad works with GCC. And finally, on a PC with low disk space, installing Visual Studio's "Desktop Development with C++" is something like 5 GB, if it was to be useful. And this is where GCC hits MSVC hard. It has native C support. MSVC can compile C, but only with a lot of fine-tuning. It takes a lot of time and effort to finally be able to compile. The final verdict:

If MSVC works, it hella works! If MSVC doesn't work, it HELLA DON'T WORK.

If GCC installs, it works, and if it doesn't work, it's the IDE's problem.

GCC is for people who don't mind spending 4 hours at the computer making it work properly. MSVC is for those who don't care about C and want it to install without any pokin' around.

View more solutions

Comments

[mikerobi]

The Intel compiler intentionally disables many of its optimizations when the code executes on AMD chips.

[Mateen Ulhaq]

@mikerobi Wouldn't that be 'antitrust' or something? Remember M$ getting sued for making it easier to use Internet Explorer, and not having APIs/etc allowing other browsers to integrate into the shell, or something like that.

[Martin Beckett]

@muntoo - no it's "a safety feature", since Intel aren't experts on AMD they couldn't be sure that their optimizations were correct ;-)

[Mateen Ulhaq]

@MartinBeckett Ah, that makes sense! And if the government could give them some money, they might be able to hire five more programmers to optimize for their largest competitor's chips...

[mikerobi]

@MartinBeckett, Intel developers don't need to be AMD experts to know that AMD's SSE instructions behave identically to there own. 3rd party compiler authors don't have inside expertise on AMD or Intel chips, but they don't have any trouble adding optimization.

[mikerobi]

@muntoo, the number of programmers has nothing to do with it. The same optimization would work on AMD chips. It is just a matter of giving their products a competitive advantage.

[rubenvb]

mikerobi: perhaps you don't see widespread use, but please look a bit further. Pretty much anything hauled over from the Linux world (here I think of things like VLC, FFMPEG, GSL, OpenOffice, KDE...) all use MinGW (GCC). When was the last time you saw a library built for all versions of MSVC? Because each version, including SP releases also breaks ABI, GCC can use one version for any GCC version (from 4.2, which is really old). I think MSVC is in the disadvantage here.

[rubenvb]

I remember this being easily circumvented (after-compile binary patch to remove the CPUID check) and I thought even removed in later ICC releases due to false competition.

[mikerobi]

@rebenvb, I did not say that it is not widespread, I said that it could be "more widespread." Linux is widespread, but that doesn't mean there isn't a lot of room for growth. I was thinking of the disapointing number of open source applications that are still compiled with Visual C++: Chrome, Firefox, MySQL, PostGreSQL, Blender, Apache to name a few. The fact that official Python releases are compiled with MSVC, is a major headache for me and forces me to use cygwin. I very badly wish you were correct when you said anything from Linux is compiled with gcc.

[Martin Beckett]

@mikerobi - you mean an almost monopolistic technology company might not have been entirely truthful in it's justification of anti-competitive behavior ? I'm shocked

[rubenvb]

Ah, yes, I forgot about the semi-commercial things. It's funny when you think of how hackish the Mozilla build system has to be (heavily modified MSYS) to be able to build with MSVC.

[timday]

See the links from this question for more on the AMD issue... stackoverflow.com/questions/839667/…

[Nairou]

That is kind of the impression I've been getting... Resulting application will be great, but the development process will be greatly diminished compared to what MSVC offers. Makes me wonder how Linux developers manage!

[Grizzly]

I haven't checked in a while, so I might be wrong, but last time I checked code::blocks didn't really convince me. Personally I would recommend either Eclipse CDT or if that uses too much resources QTCreator for mingw development

[Damon]

Eclipse has admittedly much better code completion, but it also weights about 20 times as much and takes 10 times as long to start up, etc. It's probably more powerful in its 2 million build options too, though personally this rather confuses me than being helpful. I guess it is a matter of personal taste (plus, I'm probably a bit unfairly biased to Code::Blocks). But sure enough, Eclipse may be a viable alternative.

[Eamon Nerbonne]

That's funny; in the few projects I've tried, Mingw compiles significantly more quickly and the resulting code runs faster - despite the code being being profiled and optimized using MSC (i.e. tuned for MSC not gcc).

[Damon]

@EamonNerbonne: Unless one cheats (e.g. use precompiled headers with MinGW and none with MSVC), MinGW/gcc compiles significantly (up to 2x) slower than almost any competitor, especially with optimizations. Luckily, unless dependencies are terrible, this is not really much of an issue. The reason is both the actual compiler speed, and the fact that the toolchain does a lot of forks (sometimes 4-5 per source), which is fine under Unix-like systems but pretty devastating under Windows. Plus, GNU ld performance is just abysmal. About application performance, I wholeheartedly agree...

[Damon]

... MinGW consistenly produces better code that runs faster than any competitors I know, including MSVC (that's speaking of real code, not cheating on benchmarks).

[Eamon Nerbonne]

@Damon: I'm using precompiled headers on MSCV, and not on Mingw; because they're easier to set up for msc and because; well, the slowdown in MSC is just rather annoying so I've spent more effort getting it to compile fast. I am using a lot of heavy template code from boost and some from eigen, so perhaps MSC doesn't efficiently deal with that; but any way I try and slice it; the compiles with MSC just take longer (I don't think they take quite 2x as long, but it's around that).

[HighCommander4]

I use Eclipse CDT with MinGW on Windows, and I have found its code navigation/completion features to be on par with, if not better than, MSVC's.

[Greg Kramida]

Okay guys, sorry to barge into this prolonged discussion. Found these new things by experience: (1) NetBeans is much more light-weight than Eclipse CDT for C++ compilation with MinGW / MinGW w64. (2) MinGW w64 (and the debugger) now work very well for most things, so that beats MVC C++ Express (which only compiles for x86). (3) MinGW code is leaner and meaner, therefore faster, even when trying to cut off extra lard in MVC. (4) The new OpenCL plugin for NetBeans C/C++ works great, whereas it's still a pain to get OpenCL support set up in MVC. - Hope this helps all of you C coders out there.

[Greg Kramida]

P.S.: (5) recently tried to p/Invoke C/C++ functions from an unmanaged DLL generated with MinGW w64 from a managed C# DLL (MVC#) with great success and pleasure.

[Петър Петров]

GCC DLLs can be used with MSVC EXEs if you know how to. extern "C" is here for THAT reason! Same for GetProcAddress()

[mikerobi]

@ПетърПетров, that does not work with C++, unless you build a C interface to bridge the gap. That completely changes how you have to design your application.

[user541686]

@GregKramida: Regarding point (4) -- Using the WDK can help you link dynamically to the CRT included in the OS (i.e. no need to distribute it with your programs), cutting down on the fat.

[Петър Петров]

DLLs are designed to be used as C interfaces primarily. There are protocols (Ugly hacks :P) that MSVC uses to mask these things away. Every DLL have "C" exports, even it it is advertised as a "C++" DLL. MSVC DLLs just hack that in. In MingW/GCC, you can name your C exports as you like. The way both "gamble" C++ Class methods is different, but there are macros, and you can make a macro that extend to a stub that is properly manually "gambled".

[demented hedgehog]

Some compile time speed comparisons here slashdot.org/topic/cloud/…

[mic_e]

@Nairou: Being a Linux developer, and speaking only for myself: I don't use an IDE. The command-line tools are powerful, and in contrast to languages like C# or Java, C++ wasn't built for usage with an IDE.

[Hi-Angel]

@Nairou Makes me wonder how Linux developers manage! — Linux developers usually using some kind of Vim/Emacs. Great thing when you got comfortable with it. Someone also mentioned already as IDE QtCreator. Recently I used VS2010 through VirtualBox, and I wonder how it is crippled. Though for movement I found VsVim plugin, but its debugger still much worse than the gdb. I.e. I can not set in Visual Studio a breakpoint to set a temporary break somewhere in code, and continue. Also I didn't managed to find a command for break to print a memory area… Many things, all didn't fit to a comment.

[devarni]

There is still not a good IDE with the same stability and support like MSVS also CLion plays not in the same ballpark (it's full of bugs and debugging with GDB is a nightmare).

[CinchBlue]

UPDATE: I believe CLion with its modern design, wealth of features, and CMake integration makes it worthy of being "the best non MSVC IDE on Windows." It's also more actively maintained.