- convert them over to use the newly created malloc wrapper (zmem.c), specifically utilizing the automatic destructor-on-free callback mechanism
- clean them up with consistent naming
- test for memory leaks
Then once i got vector.c, hashtable.c and linkedlist.c working at least enough to start using them:
- Take my latest opengl based project, and separate out the GL init and basic 'raw' rendering parts from the functionality of the app.
- Convert it over to use zmem and my new structures.
- Begin packaging up the basic functionality into a simple graphics library
Why am I jumping into graphics right away? Motivation. It is hard for me to stay motivated on a project that is not producing results. Once I can allocate opengl graphics buffers and get something on the screen, and see that the app does something interesting, I can stay motivated on the project. Trying to build the 'perfect hashtable' or 'perfect malloc wrapper' implementation can take a long time, and there is no clear definition of how to perfect I would like to get. Without an application, I don't know how simple or complex the API has to be; what's the point of implementing a feature that is not going to be used very often?
Once I can cleanly allocate memory, define destructors to free that memory, and can perform basic vector manipulation (which is basically just create vector, add item, remove item, and access/iterate/index those items), I can jump into graphics. I will probably not need hashtables for basic graphics; I usually don't use those until much higher level coding. (Usually to assign string names to objects, and look them up later.) Linked lists will also probably be used by graphics.