Re: List container strawman

[Ted Dennison<dennison@telepath.com>]

In article <3BE58FDD.E1FB1815@san.rr.com>, Darren New says...
>
>If you really want it to be foolproof, then for each "Location" pointer,
>you keep a pointer to the list, a pointer to the element being indexed,
>and a list number counter. In each list head, you keep a list number
>counter, a counter of the number of Location pointers outstanding, and
>the head and tail of the list.

That's not good enough either, since the List could change to make the location
itself invalid. The List itself could even go out of scope while the location
doesn't. I've implemented a lot of these types of iterators in my time, so I
have thought through the issue quite a bit already.

The best I could come up with for a Right Thing would be to keep a list of
extant Location pointers in each List object. That way the list itself can go
and invalidate the Location whenever it needs to (probably by flipping some
"valid" boolean in the Location type). Locations would have to be limited for
this to work, so the functions that return locations would have to be changed to
procedures.

To my mind, that's a rediculous amount of work and overhead to support a mild
"safeing up" of one small facility (iterators). I'm of the inlincation that if
you aren't going to do the Right Thing here, then bag it. Half-measures are
liable to cause as much harm as good by giving folks a false sense of security.
You might as well just aviod the whole issue, save all the work and overhead,
and just put it on the user to use this one feature correctly. As long as the
issues are well documented (eg: Its a "Bounded Error" to use an iterator after
any modification of its list not involving that iterator), then I don't see a
big problem.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.