Re: List container strawman

[Darren New <dnew@san.rr.com>]

Ted Dennison wrote:
> 
> 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.

I'm not sure how that could happen. The "location" record itself would
be separate from the list.

> The List itself could even go out of scope while the location
> doesn't.

Yes. That's why I suggested that it have a reference count, and
finalization would need to either be defered until all the locations are
also finalized or all locations would have to be invalidated when the
list goes out of scope.  Of course, in Ada this is probably a little
more complex, and you'd wind up with the public "List" type probably
just being a pointer to a controlled record.

> I've implemented a lot of these types of iterators in my time, so I
> have thought through the issue quite a bit already.

Yep.
 
> 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.

That could work too. You could have a linked list of Locations pointed
to by the List object.
 
> To my mind, that's a rediculous amount of work and overhead to support a mild
> "safeing up" of one small facility (iterators).

Agreed. On the other hand, you could include different bodies depending
on whether you were having trouble or not. :-) I.e., the interface
shouldn't *preclude* adding all kinds of safety checks, I think.

> 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.

Agreed. But it *is* doable. Probably not worth doing, tho. My
expectation is that it would be a debugging aid you turned on if you
need it, kind of like "Purify" for your C code.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
     Sore feet from standing in line at airport
                 security checkpoints: Jet Leg.