Re: [AD] 4.3 graphic drivers

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2005-11-11, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> On Friday 11 November 2005 10:31, Peter Hull wrote:
> > I would vote for static vtables; I think the benefits of the string-based 
> systems are small, given that the vtable wouldn't change much. How about a 
> versioned structure, ie. with a version number as the first element? 
> > 
> > typedef struct VTABLE {
> >  int version;
> >  void (*some_func)(void);
> >  ...
> > };
> 
> That will still somehow break typechecking if entries are added and it will 
> break completely in the case of addons trying to support older versions of 
> Allegro while taking advantage of new features.

How about this (partly DirectX-inspired) proposal?  Start with the first
version of the vtable.

    typedef struct VTABLE_V1 {
	void (*some_method)(int blah);
    };

    void register_vtable_v1(VTABLE_V1 *vtbl);

Drivers would statically fill in VTABLE_V1 instances, as they do now,
with type checking.

Now say we want to add a new method to the vtable, and change the
function signature of an existing method:

    typedef struct VTABLE_V2 {
	void (*new_method)(blah);
	void (*some_method)(float blah);
    };

    void register_vtable_v2(VTABLE_V2 *vtbl);

register_vtable_v1() would need to adapt V1 vtables to V2:

    void register_vtable_v1(VTABLE_V1 *v1)
    {
	VTABLE_V2 *v2 = allocate_v2_vtable();
	v2->v1_vtable = v1;
	v2->new_method = NULL;
	v2->some_method = v1_some_method_adaptor;
    }

I'm not sure where v1_some_method_adaptor is going to get the address of
v1->some_method from.  Presumably the same place as all the other
suggestions so far.  Once we decide V1 compatibility is no longer
needed, it can be thrown out.

> As for strings versus ID's... I don't have a strong preference either way 
> apart from a feeling that strings are somehow overkill.

At least with enums you get spell checking.

Peter