Question

A Scene struct has a pointer to (a linked list of) SceneObjects.
Each SceneObject refers to a Mesh.
Some SceneObjects may however refer to the same Mesh (by sharing the same pointer – or handle, see later – to the Mesh). Meshes are pretty big and doing it this way has obvious advantages for rendering speed.

typedef struct {
    Mesh *mesh; 
        ...
    struct SceneObject *next;
} SceneObject;

typedef struct Scene {
    SceneObject *objects;
    ...
} Scene;

My question:
How do I free a Scene, while avoiding to free the same Mesh pointer multiple times?

I thought I could solve this by using handle to Mesh (Mesh** mesh_handle) instead of a pointer so I could set the referenced Mesh pointer to 0, and let successive frees on it just free 0, but I can’t make it work. I just can’t get my head around how to avoid multiple deallocations.

Am I forced to keep references for such a scenario? Or am I forced to put all the Mesh objects into a separate Mesh table and free it separately? Is there a way to tackle this without doing these things? By tagging the objects as instances of each other I can naturally adjust the free algorithm so it deals with the problem, but I was wondering if there is a more ‘pure’ solution for this problem.

Answer 1

One standard solution is to have reference counters, that is every object that can possibly be referred by many other objects must have a counter that remembers how many of them are pointing it. This is done with something like

typedef struct T_Object
{
    int refcount;
    ....
} Object;

Object *newObject(....)
{
    Object *obj = my_malloc(sizeof(Object));
    obj->refcount = 1;
    ....
    return obj;
}

Object *ref(Object *p)
{
    if (p) p->refcount++;
    return p;
}

void deref(Object *p)
{
    if (p && p->refcount-- == 1)
        destroyObject(p);
}

Who first allocates the object will be the first owner (hence the counter is initialized to 1). When you need to store the pointer in other places every time you should store ref(p) instad, to be sure to increment the counter. When someone is not going to point to it anymore you should call deref(p). Once the last reference to the object is gone the counter will become zero and the deref call will actually destroy the object.

It takes some discipline to get it working (you should always think when calling ref and deref) but it’s possible to write complex software that has zero leaks using this approach.

A simpler solution that is sometimes applicable is having all your shared objects also stored in a separate list… you freely assign and change complex data structures pointing to these objects but you never free them during the normal use. Only when you need to throw everything away you deallocate those objects by using that separate list.
Note that this approach is possible only if you’re not allocating many objects during the “normal use” because in that case delaying the destruction could be not viable.