Saturday, June 19, 2010

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.

No comments: