No it's not.Klaim wrote:At the moment, the rational for using MSVC on Windows is simply that it's by far the best compiler there
mingw gcc vs. visual C++
-
- Halfling
- Posts: 54
- Joined: Thu Sep 15, 2011 4:14 pm
- x 2
Re: mingw gcc vs. visual C++
-
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
Re: mingw gcc vs. visual C++
Well, it's the faster, more optimized for windows, work well with Direct3D, the coming version even provide vectorization where possible (by default).
So, what are your arguments?
I know that gcc don't compiles faster (even in the last version that is quite an improvement), clang is almost as fast as msvc but provide better reports, intel compiler I'm not sure but from what I understand it's better on intel procs than others.
Most of the flaws in using gcc on windows is that it's not thought to be used on windows. Clang isn't complete enough yet to be used on windows, I mean the standard library more than the compiler but it's still important.
Can you give other data?
So, what are your arguments?
I know that gcc don't compiles faster (even in the last version that is quite an improvement), clang is almost as fast as msvc but provide better reports, intel compiler I'm not sure but from what I understand it's better on intel procs than others.
Most of the flaws in using gcc on windows is that it's not thought to be used on windows. Clang isn't complete enough yet to be used on windows, I mean the standard library more than the compiler but it's still important.
Can you give other data?
-
- Halfling
- Posts: 54
- Joined: Thu Sep 15, 2011 4:14 pm
- x 2
Re: mingw gcc vs. visual C++
I don't know what you mean by "optimized for windows". I don't even know what would be the benefit... faster syscalls ? They are slow for reason independent from the compiler.
To be "the best compiler" it must beat the others on every aspect. But it don't. I don't know if the output code is better optimized or not. Many people claims that VC is, but it's not what we can observe. Anyway for instance for a game using ogre development, those very small speed differences are generally irrelevant.
Why do i say so then ? Because in gcc you have far more options to control the compiler and tweak it. When you know a bit how does compilers work, you can get fine results adapted to your use case.
To be "the best compiler" it must beat the others on every aspect. But it don't. I don't know if the output code is better optimized or not. Many people claims that VC is, but it's not what we can observe. Anyway for instance for a game using ogre development, those very small speed differences are generally irrelevant.
Why do i say so then ? Because in gcc you have far more options to control the compiler and tweak it. When you know a bit how does compilers work, you can get fine results adapted to your use case.
-
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
Re: mingw gcc vs. visual C++
well, it simply exploit knowledge about the os behaviour. I mean, the standard library implementation does, using compiler-specific directives that are VC and windows specific.Valentin Perrelle wrote:I don't know what you mean by "optimized for windows". I don't even know what would be the benefit... faster syscalls ? They are slow for reason independent from the compiler.
If you use another standard library, it will certainly miss some optimizations that are platform specific.
Not for all games but lot of kind of games (like those I work on) does. Also, some kind of games just need every juice power available so in those case you consider every way is good to make the game looks good.To be "the best compiler" it must beat the others on every aspect. But it don't. I don't know if the output code is better optimized or not. Many people claims that VC is, but it's not what we can observe. Anyway for instance for a game using ogre development, those very small speed differences are generally irrelevant.
I dont know which features you cannot tweak in VS that you can in gcc, but im not a specialist.Why do i say so then ? Because in gcc you have far more options to control the compiler and tweak it. When you know a bit how does compilers work, you can get fine results adapted to your use case.
-
- Halfling
- Posts: 54
- Joined: Thu Sep 15, 2011 4:14 pm
- x 2
Re: mingw gcc vs. visual C++
Even if this is true, you can achieve comparable performances on any compiler just by optimizing for this compiler. Moreover I don't know many examples where reducing the CPU overhead is essential for the good-looking of the game. It often relies on other parameters.Klaim wrote:Not for all games but lot of kind of games (like those I work on) does.
-
- OGRE Retired Team Member
- Posts: 972
- Joined: Mon Jun 02, 2008 6:52 pm
- Location: Berlin
- x 65
Re: mingw gcc vs. visual C++
I just noticed I overlooked some previous posts to me. Will answer now:
Debugging in VS is really good. But so it is with GDB. I really did not notice a difference other than a different looking UI, obviously
Or any plugin to download and install, which you can do in NetBeans and Eclipse from within the IDE.
And probably with almost any language there is. Including almost all MS languages (I just couldn't find C#, but there is always MonoDevelop). At least for Eclipse. I think NetBeans has fever languages it supports (natively or with a plugin), but still far more than VS.
And when I say "Have fun developing Java with VS", I do not mean "Have fun developing a Java plugin for VS so you can have fun developing Java with VS." Yo dawg!
3d model placement? Sorry, I don't event know what that would mean in context with an IDE...
Node based real time shader editing? From within VS, to any project that uses shaders? I really doubt it. Or do you mean as a not-so-good replacement for something like RenderMonkey and FX Composer? If so, see the previous point
Okay, so maybe it has some more features... that are not as good as other free programs you could, and probably should, use for the issue at hand.
I'm not a fan of all-in-one solutions, they are never as good as separate, specialized programs.
W00t? When debugging my project with NetBeans (which uses GDB to do so, of course), I get immediate results and no bugs at all. Just like I was used from VS.Mikachu wrote:@TheSHEEEP : it may be true that VS competitors have improved, but how does the debugger compare to the one integrated with VS? Last time I tried GDB, it was really slow and buggy... almost impossible to use
Debugging in VS is really good. But so it is with GDB. I really did not notice a difference other than a different looking UI, obviously

I just googled for "VS Language Service Java", Ruby, PHP, Python, etc. It did not come up with any useful results.Kojack wrote:Visual Studio allows other languages to be added to it using the VS SDK Language Services, such as Iron Ruby and Cobra.Have fun developing Java and other non-MS-languages with VS
Or any plugin to download and install, which you can do in NetBeans and Eclipse from within the IDE.
And probably with almost any language there is. Including almost all MS languages (I just couldn't find C#, but there is always MonoDevelop). At least for Eclipse. I think NetBeans has fever languages it supports (natively or with a plugin), but still far more than VS.
And when I say "Have fun developing Java with VS", I do not mean "Have fun developing a Java plugin for VS so you can have fun developing Java with VS." Yo dawg!

I doubt that there are no texture editor plugins for NetBeans or Eclipse. But even if, it doesn't matter. If you want serious texture editing, you'll have to use GIMP, Paint.net, PS, etc. anyway. Why use a crappy tool (even if it is integrated) if you can have much better ones for free?Kojack wrote:Integrated texture editing, 3d model placement and node based real time shader editing?There is NOTHING VS offers that other IDEs I know and use (Eclipse and NetBeans mostly, likely even Code::Blocks) don't.
3d model placement? Sorry, I don't event know what that would mean in context with an IDE...
Node based real time shader editing? From within VS, to any project that uses shaders? I really doubt it. Or do you mean as a not-so-good replacement for something like RenderMonkey and FX Composer? If so, see the previous point

Okay, so maybe it has some more features... that are not as good as other free programs you could, and probably should, use for the issue at hand.
I'm not a fan of all-in-one solutions, they are never as good as separate, specialized programs.
-
- Gnoll
- Posts: 603
- Joined: Thu Jul 28, 2005 4:11 pm
- Location: Nice, France
- x 35
Re: mingw gcc vs. visual C++
I'm just stating my personal experience here, obviouslyTheSHEEEP wrote:W00t? When debugging my project with NetBeans (which uses GDB to do so, of course), I get immediate results and no bugs at all. Just like I was used from VS.Mikachu wrote:@TheSHEEEP : it may be true that VS competitors have improved, but how does the debugger compare to the one integrated with VS? Last time I tried GDB, it was really slow and buggy... almost impossible to use
Debugging in VS is really good. But so it is with GDB. I really did not notice a difference other than a different looking UI, obviously

It's just the point of view of some average user who isn't too familiar with GDB and just wanted to try it, without mind-twisting nor tweaking.
Last time I tried was with Code::Blocks+MingW (10.05 and latest debugger branch nightly), in a CMake generated project (I think it was Ogre's SampleBrowser).
As you say netbeans is actually good at debugging, I may give gdb another chance some day (but I think slowness came from GDB, too big project/libraries?).
Also, to add an argument in the IDE war


OgreProcedural - Procedural Geometry for Ogre3D
-
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 535
Re: mingw gcc vs. visual C++
Installer for Iron Ruby for Visual Studio 2010: http://ironruby.codeplex.com/releases/v ... dId=217152I just googled for "VS Language Service Java", Ruby, PHP, Python, etc. It did not come up with any useful results.
Or any plugin to download and install,
Installer for Python (Iron Python or CPython compatible) for Visual Studio 2010: http://pytools.codeplex.com/releases/vi ... dId=340713
Installer for PHP for Visual Studio 2010: http://jcxsoftware-download.s3.amazonaw ... php_en.msi
Hey, I'm not saying those are better features than the alternative dedicated tools, I was just providing some quick proof that your overly emphasised "There is NOTHING VS offers that other IDEs I know and use (Eclipse and NetBeans mostly, likely even Code::Blocks) don't." comment is wrong. Show me a screenshot of a node based shader editor in both netbeans and eclipse.I doubt that there are no texture editor plugins for NetBeans or Eclipse. But even if, it doesn't matter. If you want serious texture editing, you'll have to use GIMP, Paint.net, PS, etc. anyway. Why use a crappy tool (even if it is integrated) if you can have much better ones for free?
3d model placement? Sorry, I don't event know what that would mean in context with an IDE...
Node based real time shader editing? From within VS, to any project that uses shaders? I really doubt it. Or do you mean as a not-so-good replacement for something like RenderMonkey and FX Composer? If so, see the previous point
Okay, so maybe it has some more features... that are not as good as other free programs you could, and probably should, use for the issue at hand.
I'm not a fan of all-in-one solutions, they are never as good as separate, specialized programs.
Got an F# for Netbeans download link handy?And probably with almost any language there is. Including almost all MS languages (I just couldn't find C#, but there is always MonoDevelop)
VS11 includes an FBX based scene editor.3d model placement? Sorry, I don't event know what that would mean in context with an IDE...
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
Re: mingw gcc vs. visual C++
Why does this discussion remind me of VI vs Emacs, SuSE vs Redhat, ... ? 
In any case, from my experience MinGW compiles a little faster than Visual Studio, but produces larger binaries. Many Windows-centric libraries are easier to get working with Visual Studio (particularly DirectX; I had to include a couple of hacks to even get the DX9 and DX11 render systems to compile with MinGW, and the DX11 system still doesn't work). On the other hand, a couple of open-source cross-platform libraries (e.g. ffmpeg) don't work well with Visual Studio.
So choose whichever gives you the least hassle for your personal work. In my case I've found that to be Visual Studio.

In any case, from my experience MinGW compiles a little faster than Visual Studio, but produces larger binaries. Many Windows-centric libraries are easier to get working with Visual Studio (particularly DirectX; I had to include a couple of hacks to even get the DX9 and DX11 render systems to compile with MinGW, and the DX11 system still doesn't work). On the other hand, a couple of open-source cross-platform libraries (e.g. ffmpeg) don't work well with Visual Studio.
So choose whichever gives you the least hassle for your personal work. In my case I've found that to be Visual Studio.
-
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 535
Re: mingw gcc vs. visual C++
NO! You mentioned the V and E words! Now the thread will really get hostile. 
Of course visual studio and mingw aren't mutually exclusive. Back when I was doing Gameboy Advance coding our team used visual studio as the ide and mingw as the compiler. They work together fine (vs can have projects which use external tools to compile), except that gcc's error messages were a different format, but we used a wrapper to convert so we could double click on errors and jump to them in vs.
I wonder if anybody ever tried visual studio's ARM compiler with Gameboy Advance? It was mainly intended for windows mobile and windows ce, but it was still a full native c++ compiler for arm chips.

Of course visual studio and mingw aren't mutually exclusive. Back when I was doing Gameboy Advance coding our team used visual studio as the ide and mingw as the compiler. They work together fine (vs can have projects which use external tools to compile), except that gcc's error messages were a different format, but we used a wrapper to convert so we could double click on errors and jump to them in vs.
I wonder if anybody ever tried visual studio's ARM compiler with Gameboy Advance? It was mainly intended for windows mobile and windows ce, but it was still a full native c++ compiler for arm chips.
-
- Gremlin
- Posts: 170
- Joined: Tue Apr 05, 2011 1:55 am
- x 10
Re: mingw gcc vs. visual C++
My personal preference is Visual Studio, but then again that's the only one I've been using (since currently I develop Windows only). Eclipse + MingW is interesting and something I've been playing around with, but maybe once I get a graphics card that actually works with OpenGL, will I be able to finally convert my project 

During the code inspection, a couple of minor points were noticed: -
Function inlining was critical to performance.
For MSVC, at least, a "delete 0" caused execution of 11 assembly instructions, including a function call. So in cases where performance is at an absolute premium it can be worth inserting the extra manual test.
-
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
Re: mingw gcc vs. visual C++
Valentin Perrelle wrote:Even if this is true, you can achieve comparable performances on any compiler just by optimizing for this compiler. Moreover I don't know many examples where reducing the CPU overhead is essential for the good-looking of the game. It often relies on other parameters.Klaim wrote:Not for all games but lot of kind of games (like those I work on) does.
You forget that some performance optimization are performed by the compiler, making the compiler the last resort in optimization knowledge. When you optimize for a compiler (that is fine for say 99.99% of cases, I agree) you still need the compiler to know about specific optimization, so you're still "limited" by the compiler you choose.
Anyway, it don't goes against what I was saying: VC knows more about the Windows platform than gcc or clang so naturally it "might" exploit more knowledge for optimization than other compiler targetting Windows. Now, even if you don't bother about this, and that's fine, you still need to use the easiest compiler to work with on the target platform, and on windows, it's still msvc/Visual Studio. On other platform, I use the native compiler (or clang as it works like gcc).
I prefer to use the platform-specific tools. C++ code shouldn't care anyway, or should be isolated and specific if it cannot be cross-platform.
-
- OGRE Retired Team Member
- Posts: 972
- Joined: Mon Jun 02, 2008 6:52 pm
- Location: Berlin
- x 65
Re: mingw gcc vs. visual C++
Definitely! I'd love to have that, too, but I just couldn't get KDevelop compile under Windows. Too many libraries, etc. needed, Cmake issues and after some time I just gave up.Mikachu wrote: Also, to add an argument in the IDE war, I once tried KDevelop in a linux VM, and quite liked it, it's a shame there's no windows version
But it does definitely look sweet from all the screens and videos I've seen.
It's also highly ridiculous that you can get all the KDE stuff very easy for Windows. Well, everything but KDevelop, which is probably the one most coders download KDE for anyway, just to find out it is not included

Yeah, just googling "Visual Studio <language x>" gives actual results. Silly meKojack wrote:Installer for Iron Ruby for Visual Studio 2010: http://ironruby.codeplex.com/releases/v ... dId=217152I just googled for "VS Language Service Java", Ruby, PHP, Python, etc. It did not come up with any useful results.
Or any plugin to download and install,
Installer for Python (Iron Python or CPython compatible) for Visual Studio 2010: http://pytools.codeplex.com/releases/vi ... dId=340713
Installer for PHP for Visual Studio 2010: http://jcxsoftware-download.s3.amazonaw ... php_en.msi

Still, not comparable to the amount of languages offered for the oder IDEs.
Let me rephrase, then:Kojack wrote:Hey, I'm not saying those are better features than the alternative dedicated tools, I was just providing some quick proof that your overly emphasised "There is NOTHING VS offers that other IDEs I know and use (Eclipse and NetBeans mostly, likely even Code::Blocks) don't." comment is wrong. Show me a screenshot of a node based shader editor in both netbeans and eclipse.
There is NOTHING USEFUL THAT IS NOT OFFERED BETTER BY EXTERNAL PROGRAMS ANYWAY VS offers that other IDEs I know and use don't.
That sound's nice, actually.To play around with. But I really the doubt the use of it in an actual real-world project.Kojack wrote:VS11 includes an FBX based scene editor.
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: mingw gcc vs. visual C++
The idea that MinGW helps ensure cross platform code is so utterly fucked up.
And yet I keep seeing people repeating that lie and disillusion over and over..
Cross platform code is code which is tested extensively using the best tools available for the platforms on which it's supposed to run.
VC on Windows and GCC on Linux.
There is no other way.
I can't believe that there are actually people who voluntarily uses MinGW ..
NetBeans is nice, but fuck it: nothing beats the debugging facilities of Visual Studio.
As long as you write cross platform C++, your code will be cross platform.
It's that simple, d'uh.
And yet I keep seeing people repeating that lie and disillusion over and over..
Cross platform code is code which is tested extensively using the best tools available for the platforms on which it's supposed to run.
VC on Windows and GCC on Linux.
There is no other way.
I can't believe that there are actually people who voluntarily uses MinGW ..

NetBeans is nice, but fuck it: nothing beats the debugging facilities of Visual Studio.
As long as you write cross platform C++, your code will be cross platform.
It's that simple, d'uh.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: mingw gcc vs. visual C++
Usually when I see a project which is only buildable by MinGW on Windows, it means that the developers really didn't bother to write cross platform code to make it work on other platforms than Posix/*nix.
That is not cross platform, people: that is laziness.
That is not cross platform, people: that is laziness.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: mingw gcc vs. visual C++
That said: nothing wrong with MinGW per se. GCC as a compiler has several advantages. Namely better support for C++11.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Team Member
- Posts: 972
- Joined: Mon Jun 02, 2008 6:52 pm
- Location: Berlin
- x 65
Re: mingw gcc vs. visual C++
I think you are mixing compilers and cross-platform-capable code here. Or you think that others do, and may be right! I'm not sure yet 
I don't know who said that MinGW ensures cross-platform code. That's wrong. I'd say it has nothing to do with it, actually.
The cross-platform capability of the code you write is independent of the IDE and compiler. Of course, there might be some rare places in the code where one just has to mind a specific platform. But it's still one source code.
Also, I think you mistake efficiency for laziness.*
The point is that it is additional work to use different compilers/IDEs on each platform, when you can have the same result using the same compiler/IDE on each platform.
And additional work that serves no real purpose is not good, it's bad, as the time for that could be used to do something that does not work already.
Writing less code that works as well as more code would is efficient, not lazy. The result is less time consumption -> less $$ spent -> happy people!
Actually, to me, having one solution (for an IDE) that works on all platforms is more important than having one compiler that works on all platforms. I'd rather switch compilers from platform to platform than switching my development environment each time. It's just preferable if you do not have to switch anything. Just start up your IDE on whatever platform, click build, and be done with it.
So the developers did indeed bother to write code that runs on all platforms.
I really don't get your point here.
What should they have done instead? Make a solution for the poor VS people just so that those can use the IDE they are used to? Bother with CMake?
Yes, that would have been nice, as it is with the Ogre SDK, but is far from necessary and it obviously even leads to people expecting those extra services.

I don't know who said that MinGW ensures cross-platform code. That's wrong. I'd say it has nothing to do with it, actually.
The cross-platform capability of the code you write is independent of the IDE and compiler. Of course, there might be some rare places in the code where one just has to mind a specific platform. But it's still one source code.
Also, I think you mistake efficiency for laziness.*
The point is that it is additional work to use different compilers/IDEs on each platform, when you can have the same result using the same compiler/IDE on each platform.
And additional work that serves no real purpose is not good, it's bad, as the time for that could be used to do something that does not work already.
Writing less code that works as well as more code would is efficient, not lazy. The result is less time consumption -> less $$ spent -> happy people!
Actually, to me, having one solution (for an IDE) that works on all platforms is more important than having one compiler that works on all platforms. I'd rather switch compilers from platform to platform than switching my development environment each time. It's just preferable if you do not have to switch anything. Just start up your IDE on whatever platform, click build, and be done with it.
If a project is buildable on Windows with MinGW, it is buildable on Windows, and therefore, cross-platform (assuming there are other platforms it is buildable on, of course).jacmoe wrote:Usually when I see a project which is only buildable by MinGW on Windows, it means that the developers really didn't bother to write cross platform code to make it work on other platforms than Posix/*nix.
So the developers did indeed bother to write code that runs on all platforms.
I really don't get your point here.
What should they have done instead? Make a solution for the poor VS people just so that those can use the IDE they are used to? Bother with CMake?
Yes, that would have been nice, as it is with the Ogre SDK, but is far from necessary and it obviously even leads to people expecting those extra services.
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: mingw gcc vs. visual C++
If a project is only buildable with MinGW on Windows, it's not cross platform - and I won't touch it with a ten foot barge pole.
There is a reason why CMake, Premake, SConS, etc. exist.
Responsible project maintainers knows how to make use of them.
That's a part of what maintaining a cross platform codebase means.
Making sure that code compiles and links in both VC and GCC ensures that the code is cross platform, and not accidentally using GNU on Windows.
There is a reason why CMake, Premake, SConS, etc. exist.
Responsible project maintainers knows how to make use of them.
That's a part of what maintaining a cross platform codebase means.
Making sure that code compiles and links in both VC and GCC ensures that the code is cross platform, and not accidentally using GNU on Windows.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Team Member
- Posts: 972
- Joined: Mon Jun 02, 2008 6:52 pm
- Location: Berlin
- x 65
Re: mingw gcc vs. visual C++
Sorry, but you just said that a program that is buildable/runs on multiple platforms is not cross-platform. 
Of course it is nice to have support for VS/MSVC,MinGW, etc. on Windows, if we're talking about open source projects where you want to reach as many people as possible.
It is, however, never required. Take firebreath, for example. It can only be built on Windows using VS, MinGW is not possible. So, is this suddenly more cross-platform? Because, to me, it is just as restrictive as saying "Only MinGW". The result, of course, is always the same - the program will run on each platform.
But on a project, let's say a game, that is close source and has like 3-5 programmers working on it, and a budget? Every project manager that requires support of multiple IDEs/compilers in such a situation would either be ruining the budget or be -rightfully!- fired. Instead, he should enforce the use of one way, and only that one way to build the program. Whatever that way is, mind you, it might as well be a different compiler on each platform, though I doubt it. The team should agree on one way. But certainly not the capability to freely choose your compiler on any platform, as that would not yield any benefit to the project and cost time and money.
I see that you are pretty much into open source and community projects. That is fine. We all are.
But please take note that this approach with so much work put into supporting a magnitude of compilers/IDEs is simply not applicable to the majority of real world programming jobs, which are not open-source and will never be. And those projects will be cross-platform anyway.

You are wrongly applying your affection to VS into a general statement about what is cross-platform. Being cross-platforms doesn't have anything to do with how it is achieved. If it is buildable/runs on all platforms, it is cross-platform. There is nothing more to it.Wikipedia wrote:...Cross-platform software may be divided into two types; one requires individual building or compilation for each platform that it supports, and the other one can be directly run on any platform without special preparation...(the article goes on describing different techniques, programs, Java, etc.)
Of course it is nice to have support for VS/MSVC,MinGW, etc. on Windows, if we're talking about open source projects where you want to reach as many people as possible.
It is, however, never required. Take firebreath, for example. It can only be built on Windows using VS, MinGW is not possible. So, is this suddenly more cross-platform? Because, to me, it is just as restrictive as saying "Only MinGW". The result, of course, is always the same - the program will run on each platform.
But on a project, let's say a game, that is close source and has like 3-5 programmers working on it, and a budget? Every project manager that requires support of multiple IDEs/compilers in such a situation would either be ruining the budget or be -rightfully!- fired. Instead, he should enforce the use of one way, and only that one way to build the program. Whatever that way is, mind you, it might as well be a different compiler on each platform, though I doubt it. The team should agree on one way. But certainly not the capability to freely choose your compiler on any platform, as that would not yield any benefit to the project and cost time and money.
I see that you are pretty much into open source and community projects. That is fine. We all are.
But please take note that this approach with so much work put into supporting a magnitude of compilers/IDEs is simply not applicable to the majority of real world programming jobs, which are not open-source and will never be. And those projects will be cross-platform anyway.
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: mingw gcc vs. visual C++
I am referring to the topic which is about cross platform code.
I know that you can cheat and use a ported GNU system, like what MinGW provides.
That's not cross platform by the definition that I use.
Closed source or not.
For example library exports: implicit with GCC, explicit with VC.
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.
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 know that you can cheat and use a ported GNU system, like what MinGW provides.
That's not cross platform by the definition that I use.
Closed source or not.

For example library exports: implicit with GCC, explicit with VC.
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.
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.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- Halfling
- Posts: 54
- Joined: Thu Sep 15, 2011 4:14 pm
- x 2
Re: mingw gcc vs. visual C++
You should read a bit more about MinGW. MinGW only uses Msys (the ported GNU system you are talking about) to allow the reuse of building systems, and some tools. Make, autoconf, lex&yacc, and so on. MinGW doesn't require Msys to compile anything. There is no such thing as "making the compiler believe it is in a GNU environnment".
Why the use of MinGW is related to portability ? Because if your project compiles with MinGW, it compiles with GCC, and thus for any target plateform GCC has. There is 2 things in porting code from a Windows/Visual project.
I was talking about Python recently. Python doesn't support MinGW but does support Visual. It don't have much to do with the quantity of work required: mainly, it is because the wrong preprocessors tests are used. Sometimes #ifdef _WINDOWS is used when it should be #ifdef MSVC, and sometimes it is the opposite. Porting to MinGW is halfway to porting the code from Visual/Windows to GCC/*. There are some exceptions though where some windows specific library is not supported by MinGW.
Why the use of MinGW is related to portability ? Because if your project compiles with MinGW, it compiles with GCC, and thus for any target plateform GCC has. There is 2 things in porting code from a Windows/Visual project.
- If you need to change the compiler, you need to adapt to the differences of standard interpretations. GCC and Visual don't interpret the standard the same way.
- Use of system-native libraries have to be ported.
I was talking about Python recently. Python doesn't support MinGW but does support Visual. It don't have much to do with the quantity of work required: mainly, it is because the wrong preprocessors tests are used. Sometimes #ifdef _WINDOWS is used when it should be #ifdef MSVC, and sometimes it is the opposite. Porting to MinGW is halfway to porting the code from Visual/Windows to GCC/*. There are some exceptions though where some windows specific library is not supported by MinGW.
-
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
Re: mingw gcc vs. visual C++
Actually both.Valentin Perrelle wrote: Using MinGW, you only have to worry about the second one.
This very morning someone on the boost libraries mailing list pointed a bug that appear only in the implementation of mingw (because there are obviously non portable codes inside), and mingw often have bugs that are not apparent on gcc.
Also, you still don't take into account the fact that msvc on windows is obviously exploiting advanced knowledge of the OS, thing that mingw cannot do as msvc is closed source and windows too.
-
- Halfling
- Posts: 54
- Joined: Thu Sep 15, 2011 4:14 pm
- x 2
Re: mingw gcc vs. visual C++
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.Klaim wrote:Actually both.
Because i don't know what you are talking about. Exception handling ? System calls ? You have to prove that any os-specific enhancement is noticeable and that visual do something os-related that mingw does not.Klaim wrote:Also, you still don't take into account the fact that msvc on windows is obviously exploiting advanced knowledge of the OS, thing that mingw cannot do as msvc is closed source and windows too.
-
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
Re: mingw gcc vs. visual C++
I'm talking about the generated code not about libraries, once again. Check and compare assembler yourself, it's not a new fact.
-
- Halfling
- Posts: 54
- Joined: Thu Sep 15, 2011 4:14 pm
- x 2
Re: mingw gcc vs. visual C++
What should i look for in the produced assembler code ?Klaim wrote:Check and compare assembler yourself, it's not a new fact.