Idézés Aaron Griffin <aaronmgriffin@gmail.com>:
On Nov 21, 2007 9:28 AM, Justin Lampley <jrlampley@gmail.com> wrote:
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) }
Yeah. Dan suggested the same thing at one point. It's fine by me if someone wants to do this.
Here's another suggestion though, to make all our cleanup headaches... well, less painful.
struct alpm_list_t { alpm_list_node_t *first; alpm_list_node_t *last; alpm_list_fn_free *freefn; size_t size; }
then we rework alpm_list_free to do:
if(list->freefn) { list->freefn(node->data); } free(node):
Here's what we gain: * The ability to say "free all lists" in all alpm calls, while simply setting the freefn to NULL when returning package lists. * Less book keeping * No need for list freeing macros and knowing when and when not to call free_inner * No need for free_inner
Potential con: * Requires homogeneous lists that is not enforced in anyway. We do this now, but it could introduce more potential error based on the fact that we're making this op easier.
Thoughts?
Other con(?): This is an answer to both Aaron and Justin's idea. I like the idea of "list-header" (the new alpm_list_t), but alpm_list_mmerge won't like that (I refer to this possible hackish solution: http://www.archlinux.org/pipermail/pacman-dev/2007-November/010065.html) The problem is, that the list-header adds more bookkeeping to the code and we lose the current sublist-flexibility. And generating new list-headers to sublists would lead to many confusion imho. Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/