[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