RE: [AD] 4.3 graphic drivers

["Robert Ohannessian" <ROhannessian@xxxxxxxxxx>]

I seem to remember a couple of threads on the topic, a few years back...

I personally would vote for strings instead of #defines. This code
doesn't need to be fast, since it's done just once at init time.

Also, I'd like to pass an array to Allegro instead of registering the
functions individually.

For example:

	static const AL_VTABLE_1_0 my_vtable[] = {
		{ "init",  1.0, my_init  },
		{ "exit",  1.0, my_exit  },
		{ "vsync", 1.0, my_vsync },
		{ NULL,      0, NULL     }
	};
	
	GFX_VTABLE *al_vtable = create_gfx_vtable();
	register_gfx_vtable_1_0(al_vtable, my_vtable);


Where AL_VTABLE_1_0 is something like:

	typedef struct AL_VTABLE_1_0 {
		const char *function_name;
		float version; 
		void *func_ptr;
	};

Where 'function_name' is the name of the vtable entry. If the vtable
prototype for that function changes, a new name should be issued.
Allegro could then potentially implement a compatibilty layer.

'version' is the behavior version # of the function implemented by the
user. This way, if the behavior of a function has changed (slightly) but
the prototype hasn't, this lets add-ons tell Allegro which behavior they
support. Allegro could optionally do some work behind the add-on's back
to trap and fix some old broken behaviors.

'func_ptr' is just a pointer to the user function implementing the
vtable.

AL_VTABLE_1_0 and register_gfx_vtable_1_0() are versioned in case we
ever decide to change the vtable registration procedure or struct.



> -----Original Message-----
> From: alleg-developers-admin@xxxxxxxxxx [mailto:alleg-
> developers-admin@xxxxxxxxxx] On Behalf Of Peter Wang
> Sent: Wednesday, November 09, 2005 9:25 PM
> To: alleg-developers@xxxxxxxxxx
> Subject: Re: [AD] 4.3 graphic drivers
> 
> On 2005-11-09, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> > A while back there was a big discussion on allegro.cc on the merits
and
> > lack thereof for using vtables and miscellaneous other issues
> (personally
> > I think vtables are good and a powerful tool if used properly).
> > Anyway, Thomas Harte suggested that it would be a good idea to have
> > functions for creating drivers and setting vtable functions at run
time
> > (relevant post:
> > http://www.allegro.cc/forums/view_thread.php?_id=531456#target).
> >
> > Not only will this make it easier for addon writers to write and
> maintain
> > code (because nothing gets broken if the driver struct is never
touched
> > directly and we change the struct), it's also going to be easier for
us.
> > Right now if we add a function to the vtable all sourcefiles on all
> > platforms need to be edited, which is error-prone and can lead to
> > oversights.
> >
> > Attached is a proof-of-concept patch against current new_api_branch.
> There
> > are some things that need to be worked out and rewritten for this to
> work
> > elegantly but so far I already find this useful. I was able to
permute
> the
> > vtable entries and recompile without breaking anything (as long as I
> used
> > the X11 driver). I think it would be good to have a system like
this.
> >
> > Thoughts/suggestions?
> 
> The idea is fine, but you're throwing out type safety which is
crucial.
> I would prefer something simpler, like this:
> 
>    static AL_DISPLAY_DRIVER drv;
> 
>    void _xwin_create_display_drivers(void)
>    {
>       _al_construct_display_driver(&drv);
>       drv->init = _xwin_gfxdrv_init;
>       drv->exit = _xwin_gfxdrv_exit;
>       ...
>       _al_construct_display_driver_finalise(&drv);
>    }
> 
> _al_construct_display_driver() would clobber the structure it was
passed
> to all zeros.  _al_construct_display_driver_finalise() would check
that
> all the mandatory fields had been properly filled it or abort the
> program (since that constitutes an internal implementation error).
> 
> The downside compared to your system is that permuting vtable entries
> would break ABI compatibility in the case of 3rd party drivers.  IMHO
> that's not important.  It would have broken anyway if the function
> protypes or semantics changed, which is something much more desirable
> for us to do than simply reordering vtable entries.
> 
> Peter
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers