I shy away from using any kind of GC system in C++ projects, for the same reason that I shy away from all the nifty Boost features: When I need the facilities of a higher level language, I prefer to use a higher level language. ;)

What is the problem you are trying to solve with garbage collection? Are you trying to deal with cross-object references and lifetime management?

Even if you go with garbage collection, you should still avoid run-time allocations and explicitly run the garbage collector at load-time or whenever you can hide the massive frame spike you will get.

Personally I found that if the engine provides a framework in which every game object or objects of a specific system are centrally managed its easier to keep track of allocated memory and avoid leaks.
For instance, I have a render system (abstracted from any other functionality of the engine, it just knows how to render stuff) that you register all your graphic objects to, when the system is requested to shutdown or clear its contents (to change scenes or something like that) it will take the responsibility of deleting any graphic content registered to it.


The biggest advantage of smartpointers in my opinion is that you are guaranteed not to leave invalid pointers around when you do delete the object. If the likelyhood of that is very high for certain objects, smartpointers are a worthwhile solution.
Most of these problems however are avoided by being clean and organized when designing code (something that sometimes and for the peril of the programmers is skipped altogether) and having well defined interfaces to steer the users of a given code towards the right behavior.

For something like a unit in an RTS, there's a definite point where it's no longer required -- when it's been destroyed (by damage, etc).
A GC will actually get in the way of this. For example, let's say upon creating a unit, it's added to a list of "player 1's units". One of player 2's tanks then targets our new unit. The unit then self destructs and is removed from the "player 1's units" list, however, it's not yet garbage, because player 2's tank still contains a "target" reference to it, so it's not freed.

Strong/weak smart-pointers do work though -- if the "player 1's units" list contains strong pointers, but the tank's "target" link is a weak pointer, then when the unit self-destructs and removes itself from the "player 1's units" list, then the tank's "target" will be set to null automatically, and the unit freed.

As for the cost of creating/deleting units - this should be almost completely cost-free. Either creating or destroying an instance of a unit shouldn't contain much code. If you're making a lot of fixed-size allocations, then a pool allocator will work very well, and is often used for things like projectiles or 'monsters' in games that are created/destroyed often.

I'd actually suggest smart pointers.

I second that. You can use reference counting to destroy object instances when nothing holds a reference an object any longer. You can also hook up your reference count system so that the count is decremented when a smart-pointer falls out of scope... the result: automatic disposal. If you're up for a challenge and know what you're doing you can even override C++'s new and delete operators so that you can allocate all objects to a custom, managed heap; but you will need to implement heap defragmentation, optimized memory copy/move algorithms and quite a few other things. I can be done but is hard... however, the end-result can be a spectacular and efficient memory management system.

Just to demonstrate what I'm talking about:

[source lang="cpp"]void f()
{
SmartPtr<Model> pCarModel = somePtr;

// do stuff with the car model...

pCarModel->ReleaseRef( );
}[/source]

Edit:
@ATC: Damn! Ninja'd! I should have read the whole thread.

Original:

For handling instances where a unit references another unit, I.E. it's target that it is firing at, I would have a shared_ptr list of the entities in an entity factory or I would have a shared_ptr list of the entities in a factory and then a weak_ptr list of those same entities pointing to the shared_ptr entities in a target aquisition class.

Then get a weak_ptr to the object, so that we can test if it exists or not before we use it in the A.I. procedure of the thing that is targeting it.

This isn't really GC, but it's a safe way of handling inter-entity coupling that will not lead to dead pointers floating around. And I think it's a good example of the use of the weak_ptr.

A shared_ptr isn't necessarily for shared resources, it's what you use to hold a pointer to any dynamically allocated object where the dynamically allocated object exists at least for the lifetime of the object that is owning it.
weak_ptr exists to get rid of pointers that are pointing to deleted data.

And that's about what I know on the topic. I've never had the need to use unique_ptr, it's not bad or anything, it's just a tool to fit a design pattern of preventing more than 1 object from holding onto 1 value that I haven't had the need for as I don't program strict classes like that.



class EntityFactory {

std::weak_ptr<Entity> GetEntity( /* name, position, targeting data */ );

protected:
// Use a map or an oct tree depending upon your situation
std::vector<std::shared_ptr<Entity>> entities;
};

class Tank : public Entity {

void FireAtTarget() {
if( std::shared_ptr<Entity> shared_target = target.lock() ) {
// We now have a reference to target, fire at it
// maybe test if target is dead and then unset target
} else {
// Target has been destroyed, release the reference to it, or find a new target
std::weak_ptr<Entity> novalue;
target = novalue;
}
}
protected:
std::weak_ptr<Entity> target;
};



With shared_ptr and weak_ptr I don't really see the need for GC. And in addition, for things like particle systems you should be using statically allocated memory to handle those so you don't have the alloc/dealloc overhead. Like the following:



class Particle {
public:
// call ParticleAllocator::GetInstance()->CreateParticle() to get the memory for this particle
void* operator new(size_t);
// call ParticleAllocator::GetInstance()->DeleteParticle(p) to free the memory for this particle
void operator delete(void*);
};

class ParticleAllocator {
ParticleAllocator() {
hInstance = this;
for( unsigned int i = 0; i < max_particles; i++ ) {
dead_particles.push_back( &particle_memory );
}
}
void DeleteParticle(Particle* p) {
dead_particles.push_back( p );
}
Particle* CreateParticle() {
vector<Particle*>::iterator it = dead_particles.begin();
if( it != dead_particles.end() ) {
dead_particles.erase(it);
return *it;
} else {
// We have no more particles we can use
return NULL;
}
}

static ParticleAllocator* GetInstance() { return hInstance; }
protected:
static ParticleAllocator* hInstance;

Particle particle_memory[max_particles];
vector<Particle*> dead_particles;
};



This isn't really a great example of a particle system since batch rendering can't really be done with it, you might need to change it up for that but it's a good example of using statically allocated memory for dynamic objects. As a rule of thumb you want to use statically allocated memory for any dynamic object that has a short lifetime. For objects that have longer lifetimes, statically allocating memory doesn't really have much of an advantage since you end up wasting memory to ensure you have enough static allocations to meet you needs and if you're too conservative with your budget of memory for those objects you end up having bugs that arise from not having enough objects to allocate to every so often with one system or another.

As to GC.

In languages that have garbage collection generally they work by every variable in the game being passed by reference, essentially every object is stored as a shared_ptr in C++ 11 terms. And then there is a garbage collector that watches the references and deletes an object when there are no more references to it.

C# Example


// Object with value 5 created
Object myobj = Object(5)
// Object with value 6 created, object value with 5 is no longer referenced
myint = Object(6);

// Some time later: Object with value 5 is destroyed.



C++ Example


// Object with value 5 created
shared_ptr<Object> my_object = shared_ptr<Object>( new Object(5) );
// Object with value 6 created
// We do not need to delete Object(5), because it has it's reference count set to zero in the following code, it is immediately deleted.
my_object = shared_ptr<Object>( new Object(6) );


So what the shared_ptr gives you is the same sort of memory behavior of higher level languages, but much more immediately. Instead of using a GC.