Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Is it typical just to keep track within the confines of the code you're writing and explicitly free memory when you're done with it?

Yes. It's common to write OOP style C by using an opaque pointer in a header file and handle all the allocation and deallocation within the code file. The header file will export a "constructor" and "destructor" function. The constructor and destructor are still called manually, but this method properly encapsulates state to being visible only within a single code file, which prevents some accidental misuses of a type. The destructor should have a free for every allocation in the constructor, but done in reverse order. If you follow this pattern consistently, then `malloc` will only ever appear inside a constructor and `free` will only appear in a destructor. All other object allocation and deallocation is done via the relevant constructor/destructor.

.h file:

    typedef struct my_type_t my_type;

    my_type* my_type_alloc (type1, size_t);

    void my_type_free (my_type*);
.c file:

    struct my_type_t
    {
        type1 member1;
        type2* member2;
    };

    my_type* my_type_alloc (type1 m1_copy, size_t m2_size);
    {
        my_type result* = (my_type*) malloc (sizeof (my_type));
        result->member1 = m1_copy;
        result->member2 = type2_alloc (m2_size);
        return result;
    }

    void my_type_free (my_type* value)
    {
        type2_free (value->member2);
        free (value);
    }
Another technique is to make use of GCC `constructor` and `destructor` attributes, which are called before `main` and after `main` loses scope (or `exit()` is called). For example, you might have a static container type and only expose methods `add`, `remove` and `get`, then all allocation and deallocation happens solely within the code file and consumers of this API don't need to concern themselves with allocating and deallocating. This is only really useful for singleton-like (process global) data structures, but you could perhaps utilize these for implementing a GC, since an allocator is usually global to the process. (Eg, the `GC_init` function in the article could be given the constructor attribute so that the programmer would not need to manually call it).

.h file:

    void container_add (obj value);
    void container_remove (obj value);
    obj container_get (size_t index);
.c file:

    struct container_t
    {
        obj* items;
        size_t num_items;
        size_t capacity;
    }

    static container_t* c;

    __attribute__((constructor))
    void container_initialize(void)
    {
        c = malloc (sizeof (struct container_t));
        c->num_items = 0;
        c->capacity = DEFAULT_NUM_ITEMS;
        c->items = malloc(DEFAULT_NUM_ITEMS * sizeof (obj));
    }

    __attribute__((destructor))
    void container_uninitialize(void)
    {
        free (c->items);
        free (c);
    }

    void container_resize (size_t new_size)
    {
        obj* tmp = c->items;
        c->capacity = new_size;
        c->items = malloc (new_size * sizeof (obj));
        memcpy (c->items, tmp, c->num_items * sizeof (obj));
        free (tmp);
    }

    void container_add (obj value) {
        if (c->num_items == c->capacity) container_resize (c->capacity * 2);
        ...
     }

    void container_remove (obj value) { ... }

    obj container_get (size_t index) {
        return c->items[index];
    }


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: