• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Cacks

C++ Compilers & IDEs for Windows

41 posts in this topic

Hi Guys,

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

I'm making a game for PC & Mac with Linux server so looking for an option I could use on these 3 platforms,

cheers
0

Share this post


Link to post
Share on other sites
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)
1

Share this post


Link to post
Share on other sites
[quote name='Cornstalks' timestamp='1331137033' post='4920094']
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.
[/quote]

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.
0

Share this post


Link to post
Share on other sites
How about GCC as it will run on windows as well, [url="http://www.mingw.org/"]http://www.mingw.org/[/url] comes complete with Bash shell and many other nice *nix apps.
0

Share this post


Link to post
Share on other sites
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.
2

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote name='SimonForsman' timestamp='1331152541' post='4920185']
I'm using QTCreator for both Windows and Linux. (Makes things easier when i don't have to swap IDE)
[/quote]

+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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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! :-)
0

Share this post


Link to post
Share on other sites
[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! :-)
[/quote]
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.
0

Share this post


Link to post
Share on other sites
[quote name='wqking' timestamp='1331283424' post='4920616'] [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! :-) [/quote] 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 [img]http://public.gamedev.net//public/style_emoticons/default/wink.png[/img] 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.
1

Share this post


Link to post
Share on other sites
[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 [img]http://public.gamedev.net//public/style_emoticons/default/wink.png[/img]
[/quote]
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.
0

Share this post


Link to post
Share on other sites
[quote name='mhagain' timestamp='1331403038' post='4920937']
I don't think it's a valid opinion. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

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.
[/quote]
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.
0

Share this post


Link to post
Share on other sites
[quote name='wqking' timestamp='1331432290' post='4921029']
[quote name='mhagain' timestamp='1331403038' post='4920937']
I don't think it's a valid opinion. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

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.
[/quote]
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.
0

Share this post


Link to post
Share on other sites
[quote name='mhagain' timestamp='1331436293' post='4921038']
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,
[/quote]
It's not special case.
The one phase template parsing in VC can influence a lot of template code.
It's not trivial case.

[quote name='mhagain' timestamp='1331436293' post='4921038']
especially when there is plenty of code written in MSVC that can be compiled by GCC.
[/quote]
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?

[quote name='mhagain' timestamp='1331436293' post='4921038']
One case does not make it a universal law.
[/quote]
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?

[quote name='mhagain' timestamp='1331436293' post='4921038']
"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.
[/quote]
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,
[url="http://stackoverflow.com/questions/2974780/visual-c-compiler-allows-dependent-name-as-a-type-without-typename"]http://stackoverflow...ithout-typename[/url]
[url="http://stackoverflow.com/questions/6273176/what-exactly-is-broken-with-microsoft-visual-cs-two-phase-template-instanti"]http://stackoverflow...mplate-instanti[/url]

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. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] Edited by wqking
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
[quote name='SimonForsman' timestamp='1331152541' post='4920185']
I'm using QTCreator for both Windows and Linux. (Makes things easier when i don't have to swap IDE)
[/quote]
QtCreator is excellent.
0

Share this post


Link to post
Share on other sites
[quote name='Promit' timestamp='1331413251' post='4920969']
I don't think you should use GCC/MinGW on Windows unless you absolutely have to. MSVC should always be the default choice.
[/quote]
Why would this be? I ask because I would have said the same until 6 months ago. Obviously, a decision shouldn't be made based solely upon a single anecdote, but recent versions of GCC have been generating much faster code for me. The upcoming Visual C++ release might regain some ground, but I haven't tried any of the preview versions.

The general development environment in VS certainly has a lot more polish, but the decision perhaps isn't as clear cut as it was a couple of years ago (especially for people like me that don't use the IDE anyway).
0

Share this post


Link to post
Share on other sites
[quote name='edd²' timestamp='1331595194' post='4921506']
[quote name='Promit' timestamp='1331413251' post='4920969']
I don't think you should use GCC/MinGW on Windows unless you absolutely have to. MSVC should always be the default choice.
[/quote]
Why would this be? I ask because I would have said the same until 6 months ago. Obviously, a decision shouldn't be made based solely upon a single anecdote, but recent versions of GCC have been generating much faster code for me. The upcoming Visual C++ release might regain some ground, but I haven't tried any of the preview versions.

The general development environment in VS certainly has a lot more polish, but in the decision perhaps isn't as clear cut as it was a couple of years ago (especially for people like me that don't use the IDE anyway).
[/quote]

I would hazard a guess that the recent versions of GCC already support the new std::move semantics -- VS2010 does not, but the upcoming release certainly does. Move semantics will give you upwards of a 15% performance boost without doing anything at all if you're using STL in a significant way -- A little work is required to support your own types, but ought to end up producing much better code.

As for preferring MSVC in general, it's usually a hassle to use Windows' oriented libraries (say, DirectX) in GCC/MinGW, at least last time I gave it a go, but if GCC works for you, and you can put up with the slight inconveniences, it probably has the nice effect of removing a row from your platform support matrix, so do what's comfortable.
0

Share this post


Link to post
Share on other sites
[quote name='Ravyne' timestamp='1331596194' post='4921511']
I would hazard a guess that the recent versions of GCC already support the new std::move semantics -- VS2010 does not, but the upcoming release certainly does. Move semantics will give you upwards of a 15% performance boost without doing anything at all if you're using STL in a significant way -- A little work is required to support your own types, but ought to end up producing much better code.
[/quote]
Actually, it seems to be auto-vectorization and global optimization that are providing the performance win. My anecdote comes from a software renderer that does no container, string, etc copying, sorting, etc after initial set-up.

[quote]
As for preferring MSVC in general, it's usually a hassle to use Windows' oriented libraries (say, DirectX) in GCC/MinGW, at least last time I gave it a go, but if GCC works for you, and you can put up with the slight inconveniences, it probably has the nice effect of removing a row from your platform support matrix, so do what's comfortable.
[/quote]
Well, I use both, which is why I'm able to provide the observation. In general I certainly agree that Visual C++ is more convenient to get up and running, especially for a Windows-only project, but I just want to challenge the common notion (that I too held up until recently) that GCC generates slower code. Of course, this is just one project among many...
0

Share this post


Link to post
Share on other sites
[quote name='Ravyne' timestamp='1331596194' post='4921511']
I would hazard a guess that the recent versions of GCC already support the new std::move semantics -- VS2010 does not, but the upcoming release certainly does. Move semantics will give you upwards of a 15% performance boost without doing anything at all if you're using STL in a significant way -- A little work is required to support your own types, but ought to end up producing much better code.[/quote]
Huh? VS2010 supports rvalue-references, std::move and std::forward.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0