Okay so I've been delving into C++ for a couple of months now, trying out everything, using SDL, openGL, box2D etc.. and I think I'm ready to start on the project I've had in mind, but there's one thing I really fear before starting.

What's the proper way of organizing and managing my game code?

I ask because I keep seeing how even the tiniest memory leak could lead to disaster and with thousands of lines of code and dozens of files, debugging is going to be a nightmare.

First, what should I keep in mind so that debugging isn't a complete mess?
So far with all my little tests, the compiler seemed to have erratic behavior with errors. Syntax errors would get pointed to normally, but a null error would cause the game window to close. Is there an easy way to find and catch null references without having to check manually for them before using any variable? Any other debugging tips?

Second, memory issues
I basically just want a general outline of how to make sure the code structure is optimized and how to deal with memory leaks should they arise. I wouldn't want to be programming only to find out my entire code is an un-fixable mess after 4 months.

Like, any common pitfalls or an article showing the proper way to structure your code, or if anyone has any suggestions about stuff to look out for or bad practices, that'd be of great help!

Also, just to give you an idea of what I mean in case I'm not making much sense, I've only been seriously programming in Actionscript 3, where I never really bothered with removing everything when the game was done, I'd just stack what I'm going to re-use outside of the screen. But with C++, I'm the one who needs to remove *everything* when the user closes the window, so that's something I wasn't really aware of at the start.

Wow, asserts, that's a really valuable tool there, thank you Washu!

Another question just popped into my head, about exiting and removing everything, do I have to keep track of everything on screen at all times in order to know what to remove? In case the user exits at the main menu, or at a specific level, where some assets will be there and others won't.

Can't tell if you're being sarcastic here or not. But yes they are very valuable. An "assert(this);" can save you hours of debugging by simply pointing out that "this was null". An assert is not for USER ERROR, it is for the things that you are assuming are true. I.e. if you have a function that takes a string and the string must never be null... assert(string != null); can save you from going "FUUUUU". Especially since it tends to give you a nice stack trace, so you can find exactly where it's being called.

I was genuinely being grateful! I apologize if I came off as sarcastic.

Uh, asset tracking is rarely associated with the visibility of the asset, just its existence. When exiting your application you should attempt to do as little work as you have to, preferring just to clean up what needs to be cleaned up (i.e. resetting the resolution to default, maybe closing sockets, and saving any open files), and then just exit. Windows will tend to handle the rest.
[/quote]

That's actually a relief, so I don't need to remove every single variable and every single asset when closing.

Again, thanks for the speedy replies Washu! If you or anyone else still has any debugging and/or optimization "Gotcha's", feel free to post! Maybe others will benefit as well.

Wow..smart pointers. Is it just me or is C++ a very dense language? There are so many ways to do everything and so many things to take advantage of. And I thought having "pointers" was strange, as opposed to having everything just being a normal variable. What's wrong with using just regular variables anyways?

Also, another quick question. Right now, what I'm doing is putting the assets I'm using in the directory of all my source files, and in the bin/debug/ directory as well. But I imagine as the assets grow more and more, adding everything twice isn't the way everyone else does it. Or should I just keep having a copy of the assets in the bin/debug, and as well bin/release and my source directory?

IMHO, debugging is a sign of failure. It's better to write correct code than to write buggy code.

Now that's easier said than done, and noone writes 100% bug-free code. But there are some ideas that are useful.

I would not say that debugging (as in "using a debugger to find your bugs") is a sign of failure as such, but finding a bug without a clue where it originated with a debugger can be a real pain. And while nobody writes 100% bug-free code a good way to minimize bugs is to minimize your code, the less code the less bugs. Avoid code duplication under almost every circumstances except maybe for the simplest stuff. Try to find common patterns in your code and put it in a common place and don't reinvent the wheel all the time.

(could be a unit test, or some other kind of test).

Maybe have a look at Design by Contract (http://en.wikipedia....ign_by_contract) as an extension to simple Asserts to check for code correctness. But don't forget to compile the contracts out before you ship.

- Refactoring

There are two kinds of coding activities: refactoring existing code and adding new functionality. Only do one activity at a time. When refactoring, don't add new functionality, and test against existing tests. When adding new functionality, modify or design the tests first, then code (see above). Look for suitable refactorings both before and after adding new functionality.

I totally agree on that one and I like to add: Do not be afraid of refactoring. While it may be tedious to do it will lead to a cleaner code base and if it doesn't you're doing it wrong.