RE: [AD] user data

["Vincent Penquerc'h" <Vincent.Penquerch@xxxxxxxxxx>]

Title: RE: [AD] user data

> BITMAP already has `void *extra', but I suppose it doesn't hurt to add

Yes, but I heard people a while ago saying that Allegro could make
use of it in some way (such a field is only useful if one is 100%
sure Allegro will never use it). Can't actually remember when and
what about though.

> the field to other things as well (SAMPLE, RLE_SPRITE, DATAFILE,
> PACKFILE etc). It would add tons of warnings to every piece
> of existing
> code that uses DIALOG, because gcc complains when you initialize some
> but not all elements in a struct. OTOH, I think DIALOGs are the most

Only if you *use* it uninitialized no ?

> useful struct to add this to because you often extend it in
> some way. Do
> you have any particular situation in mind where this would be
> useful for
> other objects than DIALOGs?

BITMAPs and DIALOGs were the main ones, but it would be useful for
every structure that you can get from an Allegro API call (and as
such you need a way to get data from an Allegro type, so you can't
make a new strucure that contains the Allegro structure (or derive
from it in C++)).
My rationale is that it doesn't hurt to have it, as the extra data
overhead will be rather small, and will enable one to store one's
own info easily. It could be added incrementally as people need it
though.

The uses:
BITMAP: I've created a specific kind of BITMAP (I use the extra
field for this) which can reallocate itself for extra height, and
stores the additional chunks of memory in a linked list which head
is stored in the extra field. I have my own create_bitmap and
destroy_bitmap which call the original Allegro ones, then init and
free the linked list.
DIALOGS: I have a C++ widget/dialog system that relies on the
Allegro GUI system, and my widgets store a pointer to the object
representing it. I have plenty of space here, because I don't use
the Allegro widgets, but if I were doing so, some widgets use all
the fields.
That's the only two I use now, but I can see the use for PACKFILE
and DATAFILE as well. A better idea for DATAFILE could be to allow
adding properties for the DATAFILE itself, not an object in
particular. This could maybe use the special datafile object
created by the grabber.
While I'm at it, is there any reason why load_datafile_object does
not load an object's associated properties ? This can be a pain
at times...

Cheers

--
Vincent Penquerc'h