Re: [AD] 4.3 graphic drivers

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Friday 11 November 2005 13:16, Peter Wang wrote:
> But the question remains, where does `v1_some_method_adaptor' get the
> address of `v2->v1_vtable' from?  It has the function signature of
> `some_method' so the vtable is not available from its arguments.
> Presumably the currently used vtable will be stored in a global, or each
> adaptor function will have a corresponding global variable pointing to
> the function that it should call.  Those options only work if one vtable
> is in use at a time.

I've been playing around with an implementation of the 'versioned structures' 
option, which I think is similar to Peter's. 
In the case where a function's prototype is altered, and an old plugin tries 
to register a vtable with a newer Allegro, I think it's possible for the 
'register' function to build a compatible vtable by allocating extra private 
fields at the end, in which it will store the old function pointer. Assuming 
that every vtable function will take an object pointer as its first argument, 
you can get the vtable and then cast it to the version that contains the 
private fields. However, the code looks rather confusing... something like 
this:

struct private_vt {
  VTABLE_VER_2 vt;
  int (*old_somefunction)(OBJECT*, int);
};

and the adaptor like this:
int somefunction_v1_to_v2_adaptor(OBJECT* o, float arg) {
  struct private_vt* pvt2=(struct private_vt*) o->vtable;
  return (pvt2->oldsomefunction)(o, (int) arg);
}

where the API change was from int somefunction(int) in v1 to int 
somefunction(float) in v2. The definition of OBJECT is
typedef struct {
 void* vtable;
 int field1, field2, ..
} OBJECT;

Does that make sense? I need to polish up my code a bit and check it works, 
then I'll post it, which might make everything clearer.

Pete






Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/