[PATCH 2/2] tree_selected_foreach: ingore trips in the selection

[Linus Torvalds]

On Thu, Sep 27, 2012 at 3:45 PM, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> From: "Lubomir I. Ivanov" <neolit123 at gmail.com>
>
> Ignore trips (DIVE_INDEX == -1) when iterating trought the selection,
> so that we only call delete_single_dive() for dives.
>
> Signed-off-by: Lubomir I. Ivanov <neolit123 at gmail.com>
> ---
>  divelist.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/divelist.c b/divelist.c
> index 7fa6bac..d1d4038 100644
> --- a/divelist.c
> +++ b/divelist.c
> @@ -1899,11 +1899,15 @@ struct tree_selected_st {
>  static void tree_selected_foreach(GtkTreeModel *model, GtkTreePath *path,
>                                    GtkTreeIter *iter, gpointer userdata)
>  {
> +       int idx;
>         struct tree_selected_st *st = (struct tree_selected_st *)userdata;
>
> -       st->total++;
> -       st->list = (GtkTreeIter *)realloc(st->list, sizeof(GtkTreeIter) * st->total);
> -       memcpy(&st->list[st->total - 1], iter, sizeof(GtkTreeIter));
> +       gtk_tree_model_get(MODEL(dive_list), iter, DIVE_INDEX, &idx, -1);
> +       if (idx >= 0) {
> +               st->total++;
> +               st->list = (GtkTreeIter *)realloc(st->list, sizeof(GtkTreeIter) * st->total);
> +               memcpy(&st->list[st->total - 1], iter, sizeof(GtkTreeIter));
> +       }

Ugh. This is disgusting.

Why not just add a flag to the dive saying "delete me"? Do it like this:

    diff --git a/dive.h b/dive.h
    index 4d736b119b18..c04820e9611e 100644
    --- a/dive.h
    +++ b/dive.h
    @@ -252,7 +252,7 @@ struct dive {
     	int number;
     	tripflag_t tripflag;
     	dive_trip_t *divetrip;
    -	int selected;
    +	unsigned int selected:1,deleted:1;
     	timestamp_t when;
     	char *location;
     	char *notes;

and it won't use any extra space, and it's much easier for everybody to follow.

Then you can clean up the selected dives afterwards, without the
interaction with gtk iterators.

And re-allocating the array on each addition is evil anyway. Ugh, what
horrible O(n**2) behavior, although some allocators may avoid some of
it thanks to extra slack.

           Linus