I'm seeing here lots of mentions of MinGW without much acknowledging of MinGW-w64. This is important because vanilla MinGW is stuck in the pre-XP era and won't even be able to build a lot stuff made for Windows XP (and I hope you don't need DirectX because getting that to work is close to impossible), not to mention how SDL2 doesn't even work properly on it (I had to disable threading before I could get MinGW-w64 set up). Seriously, code should start including checks for vanilla MinGW and throw out an #error when detected (I just added that yesterday to my game).

Out of interest, what exactly are you referring to here? I have used both the original MinGW and its alternative (definitely in a post-XP era) and never encountered any problems like that (although I never tried DirectX with it). The biggest problem vanilla MinGW has in my opinion is the slower flow of features (as in MinGW was stuck at gcc 4.7.x when 4.8.x was already available for the other MinGWs).

One problem with all MinGWs is the issue of std::thread in C++11. Either you have to live without them (not a severe problem, especially if you use Boost anyway) or you get the standard library with POSIX threads (which works but makes the whole standard library on Windows slower than it could be). However, this seems to be a problem soon to be in the past, apparently the upcoming release at MinGW builds at least will have an implementation using native Windows thread primitives.

The biggest problem I always had was that a lot of libraries assume you'll be using Visual Studio on Windows, period, even if they use GCC on Linux instead. That's kind of ironic since MinGW(-w64) is basically half of each of those (Windows API but GCC toolchain). But yeah, enjoy messing with makefiles and such when you stumble upon one of those. I think the situation improved over time but still, take that into account. Though every time I see somebody defending Visual Studio over MinGW it's because of the IDE (I don't have any issues with using Code::Blocks but then again I don't use most of the advanced features either...)

With the libraries I wanted to use, the worst I had to do was use msys and fall back to the *nix build system. So far, that has worked even for the more annoying libraries and all it does it adding the constant cost of setting up msys once.

With the libraries I wanted to use, the worst I had to do was use msys and fall back to the *nix build system. So far, that has worked even for the more annoying libraries and all it does it adding the constant cost of setting up msys once.

Hmmm.... yes. In theory. Your mileage may vary, though (mine certainly does).

Stuff like ./configure can take anywhere from 2 to 10 minutes under Windows if you are unlucky, since it spawns a million processes. Which would still be OK if it worked 100% of the time. But sometimes msys just doesn't work properly with configure, and you need to patch a pathname or a typedef or similar. Parallel builds usually don't work at all (in my experience anyway), which is somewhat annoying in a multi-core-with-ssd world.

It is in my experience even worse if cmake gets involved (though that should actually make things easier???). For example, building OpenAL-soft regularly turns out being a total PITA for me, which usually takes all afternoon and ends with me commenting out all detection logic and hand-editing the backends section of the makefile. That's probably neither cmake's fault, nor kcat's, but it's what happens anyway.

msys is mighty fine because you almost get a complete, working Unix environment in a DOS window. I'm not complaining here, it's awesome that such a thing exists. But unluckily, sometimes almost isn't good enough.

Building GCC itself would be the prime example for a nightmare build under Windows (and for how badly msys can fail), but of course that is pretty much the worst possible case, so it's maybe kind of unfair. Still, it's no biggie to build GCC under Linux (like, uh... ./configure --with-lang=... && make && make install and taking a 10 minute break at the coffee machine), but configuring alone usually takes upwards of half an hour under Windows, and then it builds for another 30-45 minutes, creating about half a million of temporary files before it fails with some obscure error.

[stuff]

This, mostly. I don't use *nix or OSX much these days, but if I did, I'd be using clang anyway, and Visual Studio is vastly superior to any other toolchain I could use on Windows.

When I did code cross-platform, I did it by SCPing my files over from my school lab using Fedora w/gcc to home on windows w/cl and vice-versa. Actually coding on two platforms and compilers has the advantage of your programs being much more cross-platform overall -- you avoid nasty weirdnesses like how VS handles math headers differently, or C++11 support differences.

With the libraries I wanted to use, the worst I had to do was use msys and fall back to the *nix build system. So far, that has worked even for the more annoying libraries and all it does it adding the constant cost of setting up msys once.

Not gonna comment on how well this works, but every time I tried to download MSYS I was completely unable to figure out where it was. Like seriously, why isn't there a simple download for MSYS like there is for MinGW? Now mind you, it's likely I keep missing something (and if somebody can point me out that it'd be great), but it does imply that their site design isn't helping matters either.

Also it'd help if Code::Blocks installed MSYS alongside MinGW (since Code::Blocks is usually the easiest way to get MinGW going), but it'd also help if it switched to MinGW-w64 as well... (unless it did in the newest release and I didn't notice)

I'm pretty sure there is an msys download available over at the MinGW build project. I think the copy I'm using at home though originated with the vanilla MinGW install I had though.

Personally I have given up on Code::Blocks though. I used to like it, but then I ran into a sequence of builds which interacted very badly with CMake and I couldn't get a different than the bundled compiler to work. Despite previous reservations I gave QtCreator another shot when that happened and despite a few weird design decisions it has since grown on me a lot.
I'm using MSVC 2012 at work now and QtCreator at home and in contrast to what Washu says, I actually prefer QtCreator as an IDE (with the one exception of debugging).

There are some things you can't use on Visual Studio, but those are fairly far and few between.

I'm not sure I agree here either. I'm currently stuck with MSVC 2012 (still, it's post C++11) at work and haven't had a chance to work with MSVC 2013 but there are some really annoying omissions. There are the obvious ones (no parameter packs, 'infinite' parameters means five or ten) but also the little details that can cause troubles if your code is also written by Android, iOS and MacOS developers with decent compilers (like std::numeric_limits<>::max not being a constexpr).

I do use GCC on Windows. Do I win something?

If there is an actual price involved I would like to point out I was first to say "I do" in this thread. ;)

And as of today, with the offering of a Community Visual Studio 2013 which gets you plugin support I'd say there is even less reason to use anything but VS on Windows.

And the 2015 stuff which is coming is just added gravy on top... (see link).