[pacman-dev] alpm_list_t
Nagy Gabor
ngaba at bibl.u-szeged.hu
Wed Nov 21 11:18:21 EST 2007
> One possible solution is to create a alpm_list_t struct and a
> alpm_list_node_t struct like Nagy suggested in another thread. The
> alpm_list_t struct would contain:
>
> struct alpm_list_t {
> alpm_list_node_t *first;
> alpm_list_node_t *last;
> int size; (possibly)
> }
>
> We would then just turn what we currently have labeled as alpm_list_t
> into alpm_list_node_t. This would ensure that the add and remove
> functions are passed a genuine list and not a node in a list. It would
> also eliminate the need of having the head point to the tail so we have
> a quick reference to the last item in the list.
>
> The join function would then accept list1 and list2 and list2 gets
> appended to list1.
>
> list1->last->next = list2->first;
> list2->first->prev = list1->last;
> list1->last = list2->last;
>
> since we do not want a list being a subset of another list we do
> list2->first = NULL;
> list2->last = NULL;
Well, we don't want it? ;-)
/me prefers: alpm_functions treat the input as a sublist of a list (the "whole
list" is a special case of this): so we should pass the alpm_list_t parameter
and a node parameter to select the sublist (special case: node parameter ==
NULL: whole list)
> If you had the size then you could also speed up alpm_list_nth since you
> could determine whether starting from the first item or the last item
> would bring you to the nth item faster.
>
> Of course, all this would require a lot of work to change over since all
> the list looping would have to be on alpm_list_node_t types instead of
> alpm_list_t types.
>
> Just thought I would throw this idea out there and see what the rest of
> you thought.
>
> Justin
>
Overall, if we can live without "sublists", this looks good to me...
Bye, ngaba
----------------------------------------------------
SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu
This mail sent through IMP: http://horde.org/imp/
More information about the pacman-dev
mailing list