C++ Compilers & IDEs for Windows

Personally I use Visual Studio. It's really nice IDE with a lot features (including lag).

Visual Studio compiler supports only Windows as far as I know. For Mac and Linux you'll have to get GCC compiler. There's high chance you'll need to have those OSes to make programs for them (I haven't looked into cross compiling so I do know how full details)

just wondering what C++ compilers every1 uses for Windows. Does any1 use anything else than Visual studio?

If you want a cross-platform compiler and IDE, I'd suggest Code::Blocks with g++.

Personally though, I use Visual Studio on Windows, X Code on OS X, and Code::Blocks on Linux, and they all share the same source code.

Personally though, I use Visual Studio on Windows, X Code on OS X, and Code::Blocks on Linux, and they all share the same source code.

This is more or less what I do as well, although I don't target OS X (we have a build that occasionally gets shaken-down, but it's not a primary platform).

The MSVC build on Windows is considered the "master", if for no other reason because of the superior debugging facilities (gdb may be Free but it's just not in the same league - good tools are important). Most work and new development is done with this. Every few days a Code::Blocks/gcc build is also done on Windows, together with a pure makefile build on Linux. This helps to maintain cross-platform compatibility as much as possible, and shakes out any compiler or build environment oddities.

It does become quite a pain any time a new file needs to be added to the project, but the benefits outweigh.

How about GCC as it will run on windows as well, http://www.mingw.org/ comes complete with Bash shell and many other nice *nix apps.

I compile with both MinGW GCC and Visual C++ on Windows. I aim to start kicking Clang's tires soon, too.

For what it's worth, with global optimization and auto-vectorization enabled, MinGW g++ 4.6 is producing much faster code that Visual C++ 2010 for my floating-point heavy software renderer.

I'm using QTCreator for both Windows and Linux. (Makes things easier when i don't have to swap IDE)

My project works on Windows, Linux and Mac.
Primarily I debug using VC 2008 Express. That's super good to me.
On Linux and Mac, I usually don't need debug and don't write much code, so I just use CMake command line to compile and test.
When I need IDE on Linux and Mac, I use CMake to generate project file for Code::Blocks and XCode.

That's all I need for cross platform development. It's highly efficient.

I'm using QTCreator for both Windows and Linux. (Makes things easier when i don't have to swap IDE)

+1

I think this is one of the best solutions if you really don't want to change IDE and project structure. It's a robust and professional IDE.

But that wouldn't be the solution I'd choose.. I think MonoDevelop+C#+OpenTK will give you way better productivity and almost instant (if you work at it, even binary) compatibility among the platforms.

I'd use the best tool for the job, i.e. Visual studio on windows, x-code or something similar on OS-X (though I'm not sure if X-Code is the best on OS-X or not), etc. If the target is crossplattform, I'd use a crossplattform compiler/IDE. To be honest it's really annoying to switch and fix projectsettings between different IDEs and OS;es.

I primarily just use Notepad++ and MingW on windows, my favorite editor and maybe gcc on any other platform. I sync my source code with dropbox, so it's a nice and lightweight environment. Sometimes I use Eclipse, and i sort of miss VS too.

It's nice to be minimalistic, but it sure isn't always practical.
I suggest using an IDE capable of attaching a debugger, and not insist on going cross platform from the very start. -Makes life easy! :-)

I suggest using an IDE capable of attaching a debugger, and not insist on going cross platform from the very start. -Makes life easy! :-)

If cross platforms must be supported, go with it from the start will SAVE your life unless you have already very rich cross platform experience.
The C++ code written only in VC most likely can't be compiled by GCC directly. And sometimes it's not trivial to port the code.
Of course it depends on what C++ features you use. If only using very basic features such as no templates, the porting may be easier.

[quote name='SuperVGA' timestamp='1331277625' post='4920604'] I suggest using an IDE capable of attaching a debugger, and not insist on going cross platform from the very start. -Makes life easy! :-)

If cross platforms must be supported, go with it from the start will SAVE your life unless you have already very rich cross platform experience. The C++ code written only in VC most likely can't be compiled by GCC directly. And sometimes it's not trivial to port the code. Of course it depends on what C++ features you use. If only using very basic features such as no templates, the porting may be easier. [/quote]

Yes and no.

If you stick to standard C++ you'll be mostly fine, and mostly-er fine as time goes on In the far reaches of C++ space, there are still areas where the major compilers do not have equivalent support, but those are either very new things, or rather esoteric things that you're not likely to encounter anyways. That said, a few of the more-common cases that you might run across are compiler extensions and inline assembly (gcc uses a different syntax than Microsoft's compiler, for example) -- however, if you're doing either of those then you're explicitly accepting that those portions of code are not strictly portable. Something like templates are pretty safe until you start wanting to do partial template specialization, or variadic template arguments, both of which only tend to come up in relatively "advanced" scenarios.

On the other hand, the availability of libraries on the target platforms is a great deal more important. A simple example is that you can't use DirectX on MacOS or Linux platforms. A more subtle example is Boost::ASIO which is implemented very differently on Windows than it is on *nix last I heard, due to differences in the underlying platform -- even though your client code will be the same or very similar, performance might be unacceptable on one or the other platform. In general you either have to find a common library, or roll your own abstraction. When I end up doing the latter, I find that it works best to develop two or more of the "most different" implementations in parallel, and then fill in any remaining implementations later. That way you can usually avoid painting yourself into a corner, without having so much to consider that you fall victim to analysis-paralysis.

Yes and no.

If you stick to standard C++ you'll be mostly fine, and mostly-er fine as time goes on

I think "standard" is not quite equivalent to portable or cross platform.
VC is quite popular compiler but it's far less standard than GCC.
For example, VC parses template in just one phase while standard requires two phases.
That means VC has loose syntax check on template. So some template code that compiled fine in VC may fail in GCC.
And I guess MS doesn't want to change it to standard because it will break a lot of VC-only code.

Just my opinion.

[quote name='Ravyne' timestamp='1331323575' post='4920751']
Yes and no.

If you stick to standard C++ you'll be mostly fine, and mostly-er fine as time goes on

I think "standard" is not quite equivalent to portable or cross platform.
VC is quite popular compiler but it's far less standard than GCC.
For example, VC parses template in just one phase while standard requires two phases.
That means VC has loose syntax check on template. So some template code that compiled fine in VC may fail in GCC.
And I guess MS doesn't want to change it to standard because it will break a lot of VC-only code.

Just my opinion.
[/quote]
I don't think it's a valid opinion.

In a huge proportion of cases code written in MSVC is perfectly capable of being compiled on other platforms without issue or error. It's a huge jump from a bunch of interdependent "might"s and "may"s to stating that "C++ code written only in VC most likely can't be compiled by GCC directly" - especially when there are many real-life projects out there that do exactly that, and plenty of real-life people in here who have also done exactly that and can attest that it does work.

It's not the code that's going to break things, it's the libraries.

I don't think you should use GCC/MinGW on Windows unless you absolutely have to. MSVC should always be the default choice.

I don't think it's a valid opinion.

In a huge proportion of cases code written in MSVC is perfectly capable of being compiled on other platforms without issue or error. It's a huge jump from a bunch of interdependent "might"s and "may"s to stating that "C++ code written only in VC most likely can't be compiled by GCC directly" - especially when there are many real-life projects out there that do exactly that, and plenty of real-life people in here who have also done exactly that and can attest that it does work.

It's not the code that's going to break things, it's the libraries.

Did you write heavily template based code in VC then port to GCC?
I did. And due to the non-standard one phase parsing in VC, I need to change some of the code to pass the two phases check in GCC.
Of course if your code has only classes, functions, no template, it's quite portable.
In this thread nobody said their code is only classes and functions.
So I assumed template is also used.
So my opinion is valid.
That's not only my opinion, but my experience. I experiment the port issue.

[quote name='mhagain' timestamp='1331403038' post='4920937']
I don't think it's a valid opinion.

In a huge proportion of cases code written in MSVC is perfectly capable of being compiled on other platforms without issue or error. It's a huge jump from a bunch of interdependent "might"s and "may"s to stating that "C++ code written only in VC most likely can't be compiled by GCC directly" - especially when there are many real-life projects out there that do exactly that, and plenty of real-life people in here who have also done exactly that and can attest that it does work.

It's not the code that's going to break things, it's the libraries.

Did you write heavily template based code in VC then port to GCC?
I did. And due to the non-standard one phase parsing in VC, I need to change some of the code to pass the two phases check in GCC.
Of course if your code has only classes, functions, no template, it's quite portable.
In this thread nobody said their code is only classes and functions.
So I assumed template is also used.
So my opinion is valid.
That's not only my opinion, but my experience. I experiment the port issue.
[/quote]
I don't doubt that you've found a case, but going from that to "C++ code written only in VC most likely can't be compiled by GCC directly" is stretching things a little, especially when there is plenty of code written in MSVC that can be compiled by GCC. One case does not make it a universal law. "I guess MS doesn't want to change it to standard because it will break a lot of VC-only code" is definitely going too far as well.

I don't doubt that you've found a case, but going from that to "C++ code written only in VC most likely can't be compiled by GCC directly" is stretching things a little,

It's not special case.
The one phase template parsing in VC can influence a lot of template code.
It's not trivial case.

especially when there is plenty of code written in MSVC that can be compiled by GCC.

Are you sure those code are not done with extra work to port to gcc?
Or the code writer has already a lot of experience with porting between VC and gcc?
Or are you sure those code using a lot of template? Or just some pure class library?

One case does not make it a universal law.

Did I say it's a universal law? Or did I say it's a law? Please quote if I said that.
As I said, the one phase parsing in VC is not trivial case.
And even it's a trivial case, I told others about the case so they can know it and won't waste time on it.
Why are you arguing so much on this? Or do you think we can only talk about universal law here?

"I guess MS doesn't want to change it to standard because it will break a lot of VC-only code" is definitely going too far as well.

Far from what?
If MS changes one phase parsing to two phases parsing, a lot of VC code heavily using template will definitely not compile.
Isn't it that true?

Finally, did you ever write a lot template code in VC then port to gcc? Did you have any problem?

For those who are not familiar with VC template parsing issue, here are two links,
http://stackoverflow...ithout-typename
http://stackoverflow...mplate-instanti

After reading the two pages, to avoid any more unnecessary arguing, I admit my phrase "one phase parsing problem" in VC is not appropriate. It should be better "incorrect two phases parsing" in VC.

For those who down voting me, please jump out to give your reason.
Down voting others anonymously with no reason is not something a man should do.
Thanks