Re: [AD] object oriented AL_SYSTEM

["Peter Hull" <peterhull90@xxxxxxxxxx>]

What would the system object be used for? (from the Allegro user's
point of view)

There will only be one instance of it (unless we can see a need for
multiple independent Allegro systems running in the same app?) and it
shouldn't be a global variable (for DLL/.so linking issues)

Then say we wanted the OS name, the user's code could be
// Option 1
const char* os = al_get_os_name();
or
// Option 2
AL_SYSTEM* sys = al_get_system();
const char* os = sys->os_name;

The former style has more flexibility* but more impact on the namespace.

Pete

* i.e. it can return things that are not just simple properties.
Writing accessor functions like
AL_SYSTEM* sys = al_get_system();
const char* os = al_get_os_name(sys);
would seem to be unnecessary if there's only one system object -
option 1 would suffice.



On 8/27/06, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> On Saturday 26 August 2006 4:12 am, Elias Pschernig wrote:
> > How would a base structure like below look?
> >
> > struct AL_SYSTEM_DRIVER
> > {
> >    ...variables + methods
> > };
> >
> > struct AL_SYSTEM
> > {
> >    AL_SYSTEM_DRIVER *driver;
> >    ... variables
> > };
> >
> > ... for each driver XXX
> > struct AL_SYSTEM_XXX
> > {
> >    AL_SYSTEM *system;
> >    ... variables
> > }
> >
> > They would all be internal and no members accessed by the user.
> >
> > The first struct would be just like the current SYSTEM_DRIVER - i.e. the
> > "interface" or "vtable". We didn't decide yet what features we want from
> > that (there's still
> > http://awiki.tomasu.org/bin/view/Main/ProposedVTables ).
> >
> > The second struct would be an object to hold all the system specific
> > global variables, e.g. things like the detected CPU capabilities and
> > whatever else is now in global variables floating around.
> >
> > The last struct would be a driver specific version of AL_SYSTEM, which
> > could be cast to it. It would be created somewhere in al_init, something
> > like:
> >
> > AL_SYSTEM *_al_create_system(AL_SYSTEM_DRIVER *driver)
> > {
> >    system = driver->create_system(driver);
> >    ... initialize platform independent stuff in system
> >    return system;
> > }
> >
> > And driver->create_system might be:
> >
> > AL_SYSTEM *_al_create_system_x11(AL_SYSTEM_DRIVER *driver)
> > {
> >    AL_SYSTEM_X11 *system = _AL_MALLOC(sizeof *system);
> >    ... initialize driver specific stuff in system
> >    return (AL_SYSTEM *)system;
> > }
> >
> > The advantage I see in it is that we don't need internal global
> > variables floating around so much. Especially under X11, the _xwin
> > struct could go into the created AL_SYSTEM_X11 object.
> >
>
> I think it should go something like:
>
> struct AL_SYSTEM {
>         ...
> };
>
> struct AL_SYSTEM_FOO {
>         AL_SYSTEM base;
> }
>
> AL_SYSTEM_FOO can now be cast as a AL_SYSTEM just fine, and AL_SYSTEM_FOO can
> add anything it wants.
>
> --
> Thomas Fjellstrom
> tfjellstrom@xxxxxxxxxx
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers