Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: {gen,spec,sort}list stuff

[Freeciv-Dev] Re: {gen,spec,sort}list stuff

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: {gen,spec,sort}list stuff
From: Justin Moore <justin@xxxxxxxxxxx>
Date: Tue, 28 Aug 2001 15:14:56 -0400 (EDT)

> >    I rearranged the placement of the iterators and it broke things.  I'm
> > digging through coredumps trying to find it, but IMHO there's something
> > pretty broken here.  Not surprising, given the comment near the top of
> > genlist.h about iterators and placement of said macros. :) The code is
> > actually quite all right with the current element being removed from under
> > it.  How odd.
> You could clean up such things with the current genlist implementation.

   That's the plan. :)

> > I'm open to suggestions on how to cleanly remove elements from an
> > array without screwing over iterators.
> As pointed you: restarting the loop.
> > One possibility that comes to mind is to have an associated array of
> > boolean values which marks the entry as valid or not.
> Complicated.

   Somewhat, but possibly more efficient than restarting the loop.  I'll
see as I go along the pros and cons of each.  Plus, what if there are
cases in which the loop must adhere to "only-once" semantics?  Some
function that will break or return incorrect results if certain items are
iterated over more than once?

> > Plus this whole "it's-ok-for-my-current-data-to-disappear" mindset
> > is frustrating. ;p
> ??

From genlist.h, lines 84-90 (in a comment):

   Be very careful if the genlist is modified while the iteration
   is in progress.  The standard macros (based on TYPED_LIST_ITERATE
   below) allow removing the "current" element, as the iterator
   is advances at the start of the loop, but if the "next" element
   is removed (including as a side effect of removing the current
   element), expect core dumps.  See server/unitfunc.c:wipe_unit_safe()
   as an example of protecting against this.

   Removing current data is ok, but not 'next'.  Another possible (but
more involved) solution is to keep track of how many iterators are
currently looping over a list.  When an item is removed from a list, go
through and find if that deletion messes with any of the iterators.  More
complex, but more robust.  Comments?


Department of Computer Science, Duke University, Durham, NC 27708-0129
Email:  justin@xxxxxxxxxxx

[Prev in Thread] Current Thread [Next in Thread]