nesdev.org

I was using code::blocks for a while (with gcc), but the newest update crashed everytime I run the debugger. Ugh. I don't really have any interest in using anything from Visual Studio. Most of my stuff is console based with SDL and internal/custom GUI (or command line). Any recommendations?

I was using DevC++ for some time, for SDL stuff. Not pretty, but worked. It didn't have updates since 2005, though.

tomaitheous wrote:Ugh. I don't really have any interest in using anything from Visual Studio.

Can I ask why? When I read the thread title I was going to recommend exactly this.

I used eclipse + cdt + mingw.

Why not Orwell Dev-C++? It's up to date.
http://orwelldevcpp.blogspot.com.br

Zepper wrote:Why not Orwell Dev-C++? It's up to date.
http://orwelldevcpp.blogspot.com.br

I'll have to check that. I used Dev-C++ back in 2008. The lack of support is what made me switch to code::blocks. That, and the debugger ran really slow on my system for some reason. Painfully slow.

Can I ask why? When I read the thread title I was going to recommend exactly this.

I didn't want the learning curve of having to change some of my code, because of small nuances and such. I had some legacy stuff too. I needed something I could get working, easily, within a couple of days. I tend to use C++ projects with C libraries. I ran into some problems a couple of years back, doing that on VS.

I found a new updated version of lcc-win (64bit version too). Worked like a charm. I had originally used lcc-win back in 2006-2007, but the syntax is really 'laxed and I picked up some bad coding habits. That, and a lot of my code wouldn't compile on Gcc because of it.

If the problem you have with Visual Studio is the compiler, you should know that you can set up your project to use a different compiler (or linker). It can still be an effective IDE and debugger, even if you can't use its compiler for whatever reason (C99 extension compliance?).

tomaitheous wrote:I didn't want the learning curve of having to change some of my code, because of small nuances and such. I had some legacy stuff too. I needed something I could get working, easily, within a couple of days. I tend to use C++ projects with C libraries. I ran into some problems a couple of years back, doing that on VS.

When you ran into problems, were you using Visual C++ 6.0? If yes, then you should give Visual Studio another try. Because the next version after 6.0 was the first one that had an ISO-compliant compiler. So, if you write correct C++, you shouldn't run into any problems when switching from gcc to Microsoft's C++ compiler. If you still run into problems with a modern version, it would be nice if you could post an example.

As an alternative, if you really don't want to use Visual Studio, how about this:

tomaitheous wrote:I was using code::blocks for a while (with gcc), but the newest update crashed everytime I run the debugger.

Why don't you just reinstall the previous version until the next one works fine again?

DRW wrote:

tomaitheous wrote:I didn't want the learning curve of having to change some of my code, because of small nuances and such. I had some legacy stuff too. I needed something I could get working, easily, within a couple of days. I tend to use C++ projects with C libraries. I ran into some problems a couple of years back, doing that on VS.

When you ran into problems, were you using Visual C++ 6.0? If yes, then you should give Visual Studio another try. Because the next version after 6.0 was the first one that had an ISO-compliant compiler. So, if you write correct C++, you shouldn't run into any problems when switching from gcc to Microsoft's C++ compiler. If you still run into problems with a modern version, it would be nice if you could post an example.

As an alternative, if you really don't want to use Visual Studio, how about this:

tomaitheous wrote:I was using code::blocks for a while (with gcc), but the newest update crashed everytime I run the debugger.

Why don't you just reinstall the previous version until the next one works fine again?

It was VS 2010. And I don't remember exactly, the small changes I had to make in order to my compile C++ code on there.

I think, in the long run, I'll probably just switch over to VS 2010. I've been doing all my stuff with SDL and creating all the GUI interface inside the app itself. This is one of those instances where I don't actually need to re-invent wheel per se; no real benefit. I'll have to study up on how to write a win32 GUI app.

I would re-install an older version of Code::blocks, but I didn't see it listed on the main site.

tomaitheous wrote:I would re-install an older version of Code::blocks, but I didn't see it listed on the main site.

Here, maybe?

I used VS2010 for most of the development for Ghost in the Machine, then moved to VS2012 late 2013. The game also has been built for Linux and Mac OS X, and my C++ is 100% the same across platforms. Of course the build environment was different on each (g++ for linux until I switched to clang++, OS X using Xcode with clang). I'm sure you can find situations where your code will only work in VS, but I've noticed a lot of that comes from some slight laxness in implementation. By following standards, everything has worked without anything being VS / Windows specific.

Zepper wrote:Why not Orwell Dev-C++? It's up to date.
http://orwelldevcpp.blogspot.com.br

I also recommend this. It's worked pretty well for me so far, and it's just like the original, but actively maintained.

tomaitheous wrote:It was VS 2010. And I don't remember exactly, the small changes I had to make in order to my compile C++ code on there.

Well, I'm pretty positive that those error messages were justified. You know, liberties that one compiler gives you, but the other one doesn't. I doubt that if you pass an ISO-compliant code to Visual Studio, it will give you any errors. So, the errors are opportunities for you to improve the code.

tomaitheous wrote:I've been doing all my stuff with SDL and creating all the GUI interface inside the app itself. This is one of those instances where I don't actually need to re-invent wheel per se; no real benefit. I'll have to study up on how to write a win32 GUI app.

Do you write games or other applications?

DRW wrote:Well, I'm pretty positive that those error messages were justified. You know, liberties that one compiler gives you, but the other one doesn't. I doubt that if you pass an ISO-compliant code to Visual Studio, it will give you any errors. So, the errors are opportunities for you to improve the code.

There are many non-compliant things that Visual Studio does, but most compilers are guilty of this to some degree. The most glaring to me are that MSVC lacks many parts of the C99 standard, such as initializing an array length with a variable, structure initialization with named members, stuff like that. There are also some minor differences in CRT implementation, how macros with variable arguments are implemented, etc. which can often be a source of cross platform compiler errors, even though there is no logical problem with the code itself.

All that said, though, it's perfectly reasonable to learn what to avoid and develop cross platform code. I'm just saying that there are a lot of things you must do to achieve this that have nothing to do with "improving" the code, and more to do with appeasing the arbitrary whims of the compiler gods.

DRW wrote:

tomaitheous wrote:It was VS 2010. And I don't remember exactly, the small changes I had to make in order to my compile C++ code on there.

Well, I'm pretty positive that those error messages were justified. You know, liberties that one compiler gives you, but the other one doesn't. I doubt that if you pass an ISO-compliant code to Visual Studio, it will give you any errors. So, the errors are opportunities for you to improve the code.

It's possible; I won't deny that. I did a lot of coding with lcc-win compiler over the years and the syntax was so forgiving that I picked up some bad habits. I then switched over to Gcc and had to correct a lot of stuff. I thought I was writing valid C++ code, but all my experience and learning has come from looking at examples on the 'net. Everyone thinks they're right and their way is the right way. It's hard to tell who's right and who's wrong. I've had compilers where I could predefine an array with a size of say 16megabytes inside main, and then later I would get a segment error (without show what gave the segment error) because the compiler updated and wouldn't allow such a size inside main. This happened a few times. If I moved the defined array into global area, everything was fine. I've had people tell me that you should dynamically allocate that memory. And maybe so, but the compiler allows you to setup such an array - then it should have no problem creating it at run time and destroying it on exit. I understand the purpose of allocating memory and de-allocating memory, but isn't always needed especially when you only need a few arrays for something simple. What is considered 'good practice' tends to be highly opinionated.

Do you write games or other applications?

Right now? Just apps. But I have future projects that need game like engines (for prototyping console development on PC) as well as some emulation stuff.