If you want to make feature enhancment requests, the
best procedure is:
- File them in bugzilla
- (optional) send mail to gtk-devel-list if you think
that discussion on the issue would be good.
I don't think this change makes sense though:
A) g_list_free_1() doesn't unlink the list node either,
so just returning next doesn't do any good.
g_list_free_1() simply frees a single list node
that is already unlinked.
B) g_list_delete_link is exactly what you are looking for.
Regards,
Owen
Guido Draheim <[EMAIL PROTECTED]> writes:
> The glib2 function g_list_free_1 is currently defined as
> void g_list_free_1 (GList *list);
>
> This is not the best option, the function is actually
> called in many places to free the head of a glist. In
> about *all* places that includes an iteration on to the
> ->next list item.
>
> Currently, all these places make up their own tmp variable
> to store the ->next pointer for the iteration, ie. they
> do something like
> GList* tmp = list->next;
> g_list_free_1 (list);
> list = tmp;
>
> All these code points may be collapsed if the g_list_free_1
> function would be redeclared to return the ->next pointer
> all by itself, with the code parts becoming simply:
> list = g_list_free_1 (list);
>
> Looking at the implementation of g_list_free_1, a developer
> can easily see that the ->next value is accessed anyway, so
> it would not be problematic to load the ->next value into
> the return-register.
>
> GList* g_list_free_1 (GList *list);
>
> In effect, the glib code would be smaller, faster, more
> readable, and consequently maintainable. Old code may
> still ignore the return value, so that a change has only
> minimal effect on existing code.
_______________________________________________
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
