I've decided that I had enough of memory problems with c++...so no more manual memory management for me. I will use Boehm's gc from now on, which is extremely good and very very fast.

Why am I saying this? well, I've just saw another memory problem topic in the forum, and I've thought I'd share my two bits of wisdom.

People, use garbage collection! even in games! at this day and age, computers are fast enough to handle it, and the collector is very mature. Thousands of objects can be collected within a few milliseconds.

I'll stick to using RAII and wrapper classes such as smart pointers. The only hole left from that are cyclical dependencies (which can technically be addressed by a little thinking and good use of weak pointers). Most of the time either people share pointers or someone owns a pointer.

All of these are examples of objects which own memory and cleanup automatically when they get destructed. They die when they go out of scope.

Part of my research at school is looking at precise garbage collectors with C code. I have a tool that converts normal C code to use a precise garbage collector, if you want to try it.

Lack of garbage collection is still faster than the presence of garbage collection. All modern OS's (AFAIK) free the application's memory after the application closes. Things like games run for a couple of hours at a time on average, so it does not matter if they leak. I want my programs to be fast, so I purposefully leak many of my objects. I take care not too create too many, and it all works out in the end.

If you are creating objects every logic step you have a problem with the design, the solution is to alter your design, not to add a blind garbage collector I.e. there is no need for a garbage collector if there is no garbage.

If an object is created only once there is no difference whether it is freed or not. If a program leaks and it's leaks do not get worse over time there is absolutely no difference for the end user, since in the end the program uses the same amount of memory, but because of a lack of an explicit gc it runs faster.

Yes, certainly for singleton objects you don't have to free them. I probably dont reclaim those objects myself. But you made it sound like you leak various small objects because its easier to not deal delete them manually. Over time this might cause problems.

As a reasonable compromise you could just run the gc when the current level ends or some other normal pause in the game occurs. This is pretty much how I deal with all the objects in my latest game. Allocate things during the game and deallocate everything at the end of each level.

I'll second that. Memory leaks have cause a few of my programs to crash before I caught them, running fine on my system but not on older ones. Proper allocation and deallocation are staples of proper programming; to say "fsck it" and just go is madness.

You need to recognize how colossal this "if" is.

Its called a finalizer. http://www.hpl.hp.com/personal/Hans_Boehm/gc/finalization.html

Yeh I know about finalizers. They still aren't perfect. Nothing ever is though. I first learned all about them when dealing with dispose and finalize in c#.

GC's are not "way faster" than reference counting. Maybe gc's built upon reference counting are slower though.
Readable code.. if you consider boehm extensions readable and pointers not.
Faster and easier to write for.. yes and no
Yes gc's do work with c. Smart pointers require c++ to be syntactically clean. Otherwise there are a lot of winapi style dealings with structs and manual counting. (i think that's how winapi deals with it. i might be confusing them with another)
multithreaded.. Boost's pointers are thread safe. What i haven't seen is a concurrent GC.

If your design is good it is not colossal at all. If a program has many leaks it means that you are using heap allocations often. Heap is not meant to be used in that way, you are supposed to allocate and deallocate it very very sparingly. A good design does not need gc. Specifically, imo, garbage collection encourages lazy coders.

Game programming All in One!

Once i get this paperwork done i will sit down and study the papers on the boehm gc. Admittedly i haven't looked at these things in quite a while. Mostly if i want "memory woes gone" then i use a language that has a gc and has other nice things as well. Auto_ptr's have ownership and they are fast. Only penalty is in assignment. Then shared_pointers only have penalty in assignment as well.

And sieglord.. ya if you are frequently allocating and deallocating then maybe you want to set up a memory pool. Memory pools have very very fast allocations.

Garbage collection is great, in theory, as long as you keep in mind some drawbacks:

• Encourages lazier programming in general (good for quick hack-up programs, bad when the runtime performance of an algorithm is very, very important. Also encourages "static abuse" in a lot of GC-able languages (for example, concatenating two strings together in Java creates a whole new string, because strings are immutable; major performance bottleneck for those who don't watch their step).

• Adds a degree of non-determinism in program runtime (e.x. Writing a ChessAI in C# can get kinda dicey when you have a hard turn time limit.). (Referencing counting also has this problem, but not as bad. Incremental Garbage Collectors also tend to avoid this problem.)

• Sometimes you just want control of the memory allocations.

• Doesn't work with RAII (if you must allocate everything on the heap, ala java). And no, finalizers are not a substitute for RAII due to their non-deterministic execution; you know the finalizer will run, but you don't know when it will run, which can be a huge problem if you expect it to run immediately after going out of scope. (Thus, you end up having to finally blocks and other garbage to clean up after yourself, which isn't as clean as RAII.)

Basically: If the program has some hard deadlines, requires as much efficiency as possible (say, your kernel or some math function that is called thousands of times), or is highly interactive, then GC's should be used with extreme caution or avoided entirely. GC's work pretty much everywhere else, though.

Now, that given, the description of Boehm's gc via GC_malloc, it should be possible to just globally override new and delete and use them (assuming GC_malloc doesn't take any other strange arguments or have screwy side effects, as well as a GC_free existing somewhere). This would give you a really interesting benefit, in C++ in particular; you could use RAII where you want, use regular old new for everything else, and get garbage collection for free (in theory). I'd have to look up specifics and run some tests, though.