Working out the more boring parts of the project like memory, linked lists, etc

This week I'm working on the more mundane parts of the project.  I am choosing the 'best' version of hashtable, list and vector implementations and:

• 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.