Re: [AD] 4.3 graphic drivers

[Peter Wang <tjaden@xxxxxxxxxx>]

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