Re: List container strawman 1.3

["Mark Lundquist" <mlundquist2@attbi.com>]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:DpxP7.50285$xS6.83694@www.newsranger.com...
> In article <aewP7.2149$dp6.152302@rwcrnsc54>, Mark Lundquist says...
> >Ted, why does a list need to "know" when its iterators go away?
> >
> >Did you mean to say that safe iterator needs to know when its list has
gone
> >away?
>
> Yes in both cases.
>
> The iterator needs to know when its list goes away, so that users don't
try to
> whack at deallocated memory using the iterator. The list itself will have
to
> keep a mini-list of iterators to support invalidating iterators whoose
> pointed-to item is removed. The list needs to know when an iterator has
gone
> away so that the iterator's entry can be removed from this internal list
of
> iterators.

That's what I figured you had in mind :-)...

Is there an advantage of this over the approach I described, viz. lifetime
"binding" of an iterator to a list using an access discriminant?  Maybe I'm
missing something...

In the access discriminator way, any state of affairs that could give rise
to a dangling iterator results in a compile-time error, and the safety comes
at no added run-time expense.  The chained iterator approach results in a
run-time exception if a dangling iterator is dereferenced, and it seems like
it takes a lot of overhead to set things up.  Just assigning an iterator

    I, J : Iterator
    .
    .
    I := J;

is going to entail a Finalize of I (unchain it), then an Adjust to link it
back in again.  It would be best to provide the Set procedure from my
example to circumvent this, but then you might as well make the Iterator
limited.

Also of course the control structure for the list must be allocated from the
heap, so that it can outlive the user's handle (since we have to keep the
iterator chain alive until the last one goes away)...

-- mark