Zlodo

There's also www.drmemory.org, which is similar to valgrind but also works on windows.

QtCreator is pretty good and works very well even for non Qt based projects. I use cmake and qt creator handles cmake projects pretty well (with a caveat that can easily be worked around).

It is good because it's fast, with a minimalistic yet useful user interface entirely based on spliting the window into non-overlapping areas, and using drop down lists instead of tabs (which makes it much less messy to juggle between lots of files than in say, visual studio). I used to use kdevelop 4 (which also have a strong support for cmake projects) but it was a bit slow and unstable (I pretty much always had to disable the indexer).

As for other software, if you're doing C/C++ development I can't recommend cmake enough.

You can easily automatize finding out where third party libraries that you need are installed and automatically setup the necessary include and linking paths, you can easily setup unit tests and execute them automatically, you can easily do non trivial build stuff like compiling a custom code generation tool and then run it before compiling its output all with the right dependency order, and last but not least it's cross platform so if some day you want to make a windows version of your project you can still use cmake to do it.

For people curious about the 6502, here is a very impressive web-based transistor level simulation of a 6502:
http://www.visual6502.org

What sicrane said. The idea is that you need to explicitly ask for move semantics to avoid bad surprises. You don't want some function calls to steal your objects through move semantics without explcitly asking for it, which you do using std::move.

If you call a function or assign something and want to move the value instead of copying it, you do something like someFunction( move( thing ) ) or anotherthing = move( thing ). This way you know that thing is not valid anymore after that.

(btw I don't remember what the standard says about the state of an object after it has been moved, iirc it's just up to the move constructor or move operator to make sure the object is in a state where its destructor won't blow up once it goes out of scope)

I reckon the first few years of the C64's life games were written on the C64 itself, but then written on a more powerful machine in its later years such as the Commodore Amiga. Just a guess though...

I don't know if it happened on machines such as the c64 but I do know that at some point amiga games were developed using cross assemblers and debuggers running on intel PCs.

I know that reflections did this at least on shadow of the beast II and later games (they used to have interesting blurbs in the documentation of their games telling about the developpment process and it was mentioned there iirc).
Factor 5 had even developped their own intel pc based toolset called "pegasus" that they used for all their amiga and console games (probably even for their atari ports too)., I had read this in an interview somewhere.

Nowadays it doesn't makes a lot of sense to use another pc to develop a pc game, but in those days it probably made a lot of sense for professional developers to turn to that kind of solutions because machines had small amounts of memory which made it hard to have a game and development tools to coexist and even though some OSes like amiga's had preemptive multitasking they didn't provide any kind of memory protection and process isolation, which meant any unfortunate write through a bad pointer could bring the entire system down (or worse, result in filesystem or text editor buffer corruption, all kind of fun things).

Also since most games just clobbered the entire hardware and memory and interruption handlers (because using the os induced too much overhead and the hardware was fixed anyway) it was likely much easier to use remote debuggers running on the intel pc than having some hacks to let the game coexist peacefully with the os during development.

As an example of the kind of things that could happen in those days when developing directly on actual target machine , the first game that Reflections developped on amiga was ballistix. I can't remember how the hell I managed to come accross that in the first place but there were actual portions of the game's assembler source code that ended up lying around on some unused sectors of the floppy disk. Evidently that game wasn't yet using a development process using a separate pc...