Re: [AD] New mode selector, or get_gfx_mode_list(), broken[djgpp, possibly others]

[Christer Sandberg <christer.sandberg@xxxxxxxxxx>]

At 10:32 2001-09-20 +1000, Peter Wang wrote:
>On 19 Sep 2001, Laurence Withers <lwithers@xxxxxxxxxx> wrote:
>> In reply to Peter Wang <tjaden@xxxxxxxxxx>:
>> >I also think an array is the right choice here, rather than a linked
>> >list, but I'm not sure why.
>> 
>> But what if I want to join or delete lists, etc. This would be useful in
>> the mode selector. This is fiddly, annoying and bug-ridden with arrays,
>> and simple and easy with linked lists.
>
>Wouldn't you still have a bunch of allocations and pointer voodoo to
>do?  How would you free your list?  It be ugly to use `malloc' to
>create your own list elements, then use `destroy_gfx_mode_list' (and
>might actually be wrong, in some circumstances).  And sorting a
>linked list is relatively hard.

I can't see that the implementation of the list is very important. Maybe
there should be worth putting some work on making the implementation
hidden. I.e. the create/destroy are alredy there, possible other operators
might be something like: getfirst, getnext, append, sort. 
(Just to remain about some basic concepts:-)

Sorting, concatenating, allocating etc. one implementation type is really
not more tricky than the other (they all follow well-known pattern). E.g.
insertion sort in a linked list will not be more than a few lines of code,
concatenating two arrays by use of realloc and memmove should not be very
much either. So which one is choosed is not very important (probably I
would have choosed an array of pointers to get optimal use of qsort).

If one successed in hiding the implementation of structures (like "list of
graphic modes") one is free to make any implementation changes at any time,
without even update the docs or mention in the official release info that
there has been a change. As long as the names and semantic of the operators
are unchanged all applications will work as before.

This is a general approach for working with libs that I think is important.
I am aware that there are other concepts than the "gfx_mode_list" in
Allegro, and I really don't meen that there is necesary to re-write
something of it since, most of it is really good (many of the Allegro
fuctions are also critical for performance which maybe make it necessary to
sacrify some generality). However this one is less critical (no repeated
operations during each frame), and if one anyway is about to make changes,
the above may be worth thinking of.
/C