mingw gcc vs. visual C++

[TheSHEEEP]

I don't normally support MinGW for my projects, because it's too much work, but I make sure that it works with GCC and VC.
Using different compilers is very helpful in discovering those bugs that you wouldn't otherwise have been aware of due to the differences between the two.

Bugs that wouldn't exist, would you not switch compilers. Congratulations

I agree with Klaim that you are better off using the tools which goes with the platform you're using as it yields the best performance.

I would agree if the performance boost was actually notable. And to me, "notable" is 5% and more performance increase. And I really, seriously doubt that the difference is that big in 99% of projects.
Especially in game applications where the bottle neck in most cases is the GPU, which should be unaffected by the compiler used anyway.

In the end, you'll have to decide for yourself if it is worth the hassle.
Let's just assume the performance boost is that big. If you really need that 5% boost to get your game going on your target machines in 60+ fps*, then maybe the problem lies within the code, not within the compiler...

Also, what do you want to do with libraries that are not compilable under Windows with MSVC?
Just ignore them? Well, good luck doing video and audio manipulation from code without ffmpeg**


*I kinda lost track of what the target value is nowadays, as I code so much ActionScript, the 30 fps has burned into my head, replacing all other values.
**"FFMPEG DOES NOT BUILD UNDER MSVC++, AND WILL NOT, EVER, BUILD UNDER MSVC++.
MSVC++ still does not adhere to the C99 standard, and FFmpeg relies on it, because its developers chose to rely on it.
This means the entire build process of FFmpeg must be done with MinGW."

[CABAListic]

The biggest issue with MinGW and games development on Windows is still the fact that it's a royal pain in the ass to get it working with the DirectX SDK. At least a MinGW compiled ffmpeg DLL probably works without ugly hacks with MSVC. Can't say the same about DirectX

[_tommo_]

I don't think I have EVER had a bug due to compiler differences, and I'm using MSVC10, LLVM3 and GCC4.5 at the same time, on two different and big projects.

Do yourself a favor, study what means to write clean C++ (and use platform-specific compilers) instead of blaming microsoft

[Kojack]

MSVC++ still does not adhere to the C99 standard, and FFmpeg relies on it

GCC doesn't fully support C99 either. Only 4 features of it are used in ffmpeg and the developer docs say to not use any other C99 features.



The ffmpeg developer policy actually states:

15. Never write to unallocated memory, never write over the end of arrays

They really need to make a rule to stop their developers from doing that?

[TheSHEEEP]

The ffmpeg developer policy actually states:

15. Never write to unallocated memory, never write over the end of arrays

They really need to make a rule to stop their developers from doing that?

Okay, that one's nice.
But anyway, it is an open source project and due to that probably subject to some people not knowing that basic rule? I don't know, maybe they just wanted to be really, really sure
Don't get me wrong, I really don't like the ffmpeg library. It is a hard to use, pure C, non-OO (yuck!) library with severely lacking examples that is a pain to use when using the API directly... It's just the only free way to do what it can do, unfortunately.

The biggest issue with MinGW and games development on Windows is still the fact that it's a royal pain in the ass to get it working with the DirectX SDK. At least a MinGW compiled ffmpeg DLL probably works without ugly hacks with MSVC. Can't say the same about DirectX

Can't argue with that. Then again, why not use OpenGL? Please don't tell me it's faster on Windows

[CABAListic]

Hm, it's kind of a vicious cycle. Since few people are using OpenGL on Windows, driver support for it was considerably worse than for DirectX in the past. It's not just performance issues, but also bugs in certain features etc.. Of course, it's hard to pin down as drivers are constantly changing, and usually Nvidia worked better than AMD. I don't know what the current situation is like; if you are not doing anything too fancy/advanced, you're probably fine.

[jacmoe]

Actually both.

You can't say that the very small number of Mingw specificities is comparable to the number of differences between gcc and visual. There are numerous libraries that compiles both on gcc and mingw without any use of #define.

Really??
Must be trivial C libs then.

Supporting MinGW is a lot more work in my experience, it is a whole new world of pain compared to GCC.

There are 5 times more conditional defines to support MinGW than there are for GCC and VC..

So it is pure laziness on my part that I don't support it.

Supporting VC on Windows and GCC on *nix is actually less work.
And it makes my code better.

[Kojack]

Don't get me wrong, I really don't like the ffmpeg library. It is a hard to use, pure C, non-OO (yuck!) library with severely lacking examples that is a pain to use when using the API directly... It's just the only free way to do what it can do, unfortunately.

There's libav, but since it's a fork of ffmpeg it doesn't really count.

It still amazes me just how annoying it is to handle video these days.
So far the easiest api I've found for extracting frame data from a video is actually Video For Windows. It consists of one header and one lib that come with the windows sdk. After setting it up with a small bit of code, you just call a function with a frame number and it returns a pointer to a bitmap. Copying that over to an ogre texture is simple.
But VFW was abandoned years ago, and it only seems to work with a few crappy codecs in an avi stream, and it's not cross platform.
(VFW was replaced by Active Movie, which was replaced by Direct Show, which was replaced by Media Foundation. VFW still works fine though)


On this whole cross platform thing, I would say that a project that only compiles on mingw on windows (like ffmpeg) is cross platform (works on multiple hardware and os platforms) but isn't portable (has trouble in certain compilers).
If it only compiles and runs using cygwin, then I wouldn't call it cross platform (since cygwin provides a linux api for software that otherwise can't handle a windows environment).

[Valentin Perrelle]

There are 5 times more conditional defines to support MinGW than there are for GCC and VC..

Then you are probably not using it correctly. As i stated before, preprocessor conditions are usually not used properly. Please note that MinGW is not what it was ten years ago. The first time i tried to use it, it was a nightmare. Porting code to MinGW nowdays is not much work. The only problem is that i have to do it myself. The three last libraries i ported, here's what i needed to do :

• Remove exceptions that have been put here for MinGW when latest version of MinGW was working the same as GCC/Linux.
• Change #ifdef _WINDOWS by #ifdef MSVC or things like that.
• Change the building system (handwritting a Makefile or using cmake)
• Add some flags to GCC, when the code uses non-standard or borderline tricks.

[Trioxin]

An observation of mine is that all programs compiled with visual C++ require the VC++ redistributables installed. This includes a simple "Hello world!" application.

Since all my creations use OpenGL as the primary renderer, I'm doing my development in VC++ simply because I find it has the nicest interface and debug tools of all environments I've ever seen, but come release time I'd be switching to MinGW to get rid of that pesky dependency.

[jacmoe]

Since VC10 that's not really an issue: you merely copy the vc dll over. You have to do the same thing for MinGW (dll copy).
Which is why I am not switching to MinGW come release time.

@Valentin: You are probably right. I just found it to be really quirky.

[bstone]

An observation of mine is that all programs compiled with visual C++ require the VC++ redistributables installed. This includes a simple "Hello world!" application.

Besides what jacmoe said (and he's absolutely correct) you can use static linking with VC that avoids having any run-time DLLs at all. And no way you could do that with MinGW unfortunately.

[Valentin Perrelle]

And no way you could do that with MinGW unfortunately.

You can do it with mingw using the (gcc) flags -static-libgcc and -static-libstdc++. However the first one can't be used if exceptions have to be caught by a dynamic module. This said, if you are in the last case, you are likely to distribute the dll catching the exceptions and it is thus not a big deal to distribute the mingw dll as well.

GCC documentation

Static linking with standard lib/compiler lib is a basic feature supported by most compilers.

In theory, static linking could be used to achieve a lower total binary size since you can remove symbols and dead code at compile time. With mingw, using the two flags mentionned above doesn't reduce the total size. I didn't test this with MSVC.

[bstone]

No, the problem with MinGW and static linking is in the legal space. GCC can do static linking without problems, but you are not allowed to link statically against MSVC run-time libraries for copyright reasons.

[Sqeaky]

Sorry if I am necro-ing this thread, but I can't stand claims without evidence, particularly when evidence abounds. Type in "gcc vs visual c++" then click "I'm feeling lucky" and you will get: http://www.g-truc.net/post-0372.html

He clearly demonstrates that on older machines without SSE that VC++ is clearly faster, and that on more modern machines 64 bit or 32bit with SSE GCC 4.X is faster than all but the newest version of VC++, and even then it is neck and neck. This is not a complete benchmark, but it does show that the subject is more complex than X is better than Y.

Onto the opinion piece of this.
With VS outside of the default configuration there can be plenty of headache's. You are expected to know tons of specific obscure and poorly documented and oddly specific facts to get things working when you step outside the very carefully controlled pre-built microsoft environment (I never could get the libgmp object files from mingw to be correctly linked by VC++ despite multiple docs with precise procedures and thorough explanations). Doing wierd stuff with open source tools is much easier in general, not that I do it often, but when I have to, I do not want seemingly artificial restrictions.

What about QT creator as an IDE has anyone else used that? It works on Linux, Windows, and Mac OS X, Seamless integration with Git or Svn, Cmake, works with your choice of c++ compiler (VC, Mingw, GCC). It certainly crashes less than VS and other than the tooltips during it seems better in almost every way. On the downside it only works with C/C++ and does support all the autocompletion type stuff for C++11 yet.

[TheSHEEEP]

Is QT creator really capable of doing all the things with C++ you can do with VS/Eclipse/NetBeans? I mean adding any libraries, using GCC, debugging, etc.

I had a look at it, but not very close and I assumed it was mainly for QT development and not really or less useful for anything else.

So basically the name "scared" me off.

[tomkcook]

It's probably stupid to jump in on this sort of discussion, but...

I use VC++ in my day job (both 2008 and 2010). I use Eclipse for my personal project development. I prefer the latter immensely. This is largely because source code navigation and intellisense work so much better in Eclipse than in VS. It's quite a recent thing to be able to say this - a couple of versions ago, CDT was dreadful. But, as with all things Eclipse, if it kind of works in version X, it will work well in version X+1 and perform well in version X+2. CDT is now much more productive for me than VS. In particular, the VS refactoring tools for C++ are a joke compared to Eclipse/CDT.

It should be noted that I am working on Linux with Eclipse. I'm about to start ensuring I can build under MinGW, so perhaps I'm about to find out whether CDT on Windows is as good as it is on Linux.

From my initial impressions (and I think the history of this thread backs me up), the main thing arguing one way or the other between current versions of VS and CDT or VC++ and MinGW are not the quality of the UI or debugger but just the degree of pain involved in getting all your dependency libraries to work with your toolchain of choice. For me, I've developed against:

• GTK+ 3
• GTK-- 3
• OpenCV 2
• Ogre3D
• OpenAL

The thing that will determine which environment I end up using on Windows will not be which one provides the best IDE but which one provides the path of least resistance the getting all these dependencies linked in correctly.

My $0.02

Tom

[Macros]

printf("%Lf", 1.L);

[Softstar]

I have using code::Blocks(mingw gcc 4.7.1) for several month, it is very friendly. Different colour for marking c/C++ keyword, and it auto retract

[Magnus]

I personally prefer VC++ because it's easy to use and doesn't have to configure a lot of things to start working.