I've gone CScript.
After having a C++ macro processing language at my disposal for about 15 years now, i've finanlly made the big move and fully integrated CScipt into my code development workflow. now if there was just a way to add a solution specific external tool button to the standard menu bar in VC 2012 express.....
See this journal entry from Project Z for more info on CScript....
https://www.gamedev.net/blog/1731/entry-2258676-the-cscript-macro-programming-language/
So far, i couldn't be happier. With translation times on the order of 100,000 lines per second, the CScript macro processor stage of the new build pipeline is just a blink of an eye!.
and now i can write new code as well as modifiy existing code using CScript syntax, which is quick and easy.
Here's an example of some of the new new CScript code i'm writing now. This is an implementation of a GUI button system i added to the Z library. Granted, its only a statically allocated array with a hard coded size. but it can easily be converted to a class that gets passed a size on creation. an app will generally know how many buttons they need in a given list of buttons. in cases where they don't, a vector would do nicely in place of an array. I created it with updating the UI of the rigid body modeler/animator in mind. the modeler/animator is a linkable module with just two screens of maybe 20 hotspots each. so a single list of 100 buttons was fine for a start. in the long run, this api would evolve to have the ability to load land save lists of buttons, and store an array of button lists (or perhaps a tree for a menu hierarchy). one might even implement a callback driven event handler for it.
this CScript code is a full implementation of a buttonlist data structure with init, new, release, get, set, draw, and pick functions:
' ####################### buttons list ##############################
#d Zmaxbtns 100
st Zbtnrec
i x y w h texID active
s text
.st
Zbtnrec Zbtn[Zmaxbtns];
fn v Zinit_btns
c ZeroMemory &Zbtn sizeof(Zbtnrec)*Zmaxbtns
.
fn i Znewbtn
i a
4 a Zmaxbtns
== Zbtn[a].active 0
ret a
.
.
ret -1
.
fn v Zreleasebtn i a
= Zbtn[a].active 0
.
fn v Zsetbtn i index i x i y i w i h i texID c *text
= Zbtn[index].x x
= Zbtn[index].y y
= Zbtn[index].w w
= Zbtn[index].h h
= Zbtn[index].texID texID
ss Zbtn[index].text text
.
fn v Zgetbtn i index i *x i *y i *w i *h i *texID c *text
= *x Zbtn[index].x
= *y Zbtn[index].y
= *w Zbtn[index].w
= *h Zbtn[index].h
= *texID Zbtn[index].texID
ss text Zbtn[index].text
.
fn v Zdrawbtn i index
!= Zbtn[index].texID -1
c Zdrawsprite Zbtn[index].texID Zbtn[index].x Zbtn[index].y (float)Zbtn[index].w/256.0f (float)Zbtn[index].h/256.0f
.
!= strcmp(Zbtn[index].text,"") 0
c Ztext Zbtn[index].x+10 Zbtn[index].y+10 Zbtn[index].text
.
.
fn i Zisinbtn i x i y i index
i a
cr a isin x y Zbtn[index].x Zbtn[index].y Zbtn[index].x+Zbtn[index].w Zbtn[index].y+Zbtn[index].h
ret a
.
exercise for the reader:
follow the link, and use the CScript language description to translate this into a C++ class definition that takes a button list size as a creation parameter, and uses an array as its in internal data structure. I'm thinking the object would have a btnrec pointer and malloc and free in the constructor and destructor. I know! why not use vector?
because both type and size of the array are known ahead of time (at compile time, or at runtime in the case of soft coded button lists). variable size and type are not needed, and are there for unnecessary overhead and unnecessary complexity.
this is one of the the essences of the different way.
DON'T OVER-ENGINEER IN ANTICIPATION OF A FUTURE THAT NEVER COMES.
Design with ease of modifiiability in mind, but don't do the mods til needed.
With a clean decoupled API, this type of code module can be converted from internal use of array to vector without breaking any of the games or apps that use it. If you hit that rare case where you don't know how may buttons a screen could possibly have, then go for the vector. until then, avoid overhead, avoid hassle. code for simplicity. code for speed.