> Never actually done it, but I've considered doing something based on
> arrays...it'd be hellishly complex and inefficient. And it was limited
> to passive data structures, not really anything like objects.

Well that's kinda similar to what I'm thinking.

my theory is I interface to everything via macros. So if I want to get the
"position" member of an object that I have "pointer" to, this would actually
work by using indeces, not pointers, and having an array of positions. But I can
write the code via macros so it looks sorta like it's using structures!

The problem with this is that I need one set of arrays for each different class
of object/structure. And those arrays would need to be long enough to hold every
instance I would be likely to create. Still, that's not a big problem.

The other, much more cunning, trick is to be able to have functions (actually
macros) invoked differently for different objects. e.g. lets imagine I have lots
of classes that have the same basic structure, but different functions (e.g.
good guys and bad guys with different AI routines). The thing is I want to be
able to invoke different functions according to what class of object I'm
accessing *without needing a big switch statement handling all classes*.

My cunning trick is to store, as a parameter in the "structure", the name of the
macro I want to invoke for this object. e.g. "GoodGuyUpdate". Then I can save
this string out to a scratch file with a string of parameters (which will be the
same since this is just an implementation of a virtual function, if you want to
look at it like that). So we get a scratch file saying
"GoodGuyUpdate(myObject,deltaTime)" or something. Then just include that scratch
file to invoke it!

It's somewhat cumbersome, but it would certainly work.

In fact, I think I'm gonna start building this framework now :)

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message