Re: [AD] load_datafile_object with properties

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

[Sorry about the delay]

> Ok, in this version, I fixed everything mentioned, and converted it to a
> linked list with a public API. About the public API, i went a middle
> way, and only made the add-to-list function public, but left the
> clear-complete-list static. My reasoning was, in case a user would want
> to do this for whatever reason, the former is quite lengthy, but the
> latter is only a one-line loop.

Thanks.

> Changing to a linked list required many changes in the datafile tools
> (see my patch), so if you want, I can still send a fixed version of my
> first patch using arrays, and only changing datafile.c. But I remember,
> there are other changes going on in the datafile tools, so maybe now is
> a good time for this anyway?

I didn't realize that switching to a linked list involves so many changes...
the question is now: are they really worth implementing ? I don't think many
users attach more than 64 properties to their objects.

> I didn't adapt the dat2c and dat2s programs yet, because I'm not sure
> what's the best way to hard-code a linked list, all solutions without
> some sort of constructor function seem to either require many variables
> or be a bit hackish. So be warned, the patch breaks them both.

Ah! yes, dat2s/c don't play nice with linked lists.


Have you already written the fixed version of your original patch you talk
about above ? If so, post it on the list, I now think it's the most
reasonable solution (and Allegro already uses this type of container for its
gfx mode list fetching code). If no, I'll write it myself as a due
punishment for not thinking about the consequences of my suggestion :-(

--
Eric Botcazou