From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,93ab7fc5388e249 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-05 15:59:32 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!netnews.com!wn1feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi.com!rwcrnsc54.POSTED!not-for-mail From: "Mark Lundquist" Newsgroups: comp.lang.ada References: <3C0E1FA1.45A38A75@brighton.ac.uk> <%7sP7.49836$xS6.82296@www.newsranger.com> Subject: Re: List container strawman 1.3 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Wed, 05 Dec 2001 23:59:31 GMT NNTP-Posting-Host: 204.127.202.215 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc54 1007596771 204.127.202.215 (Wed, 05 Dec 2001 23:59:31 GMT) NNTP-Posting-Date: Wed, 05 Dec 2001 23:59:31 GMT Organization: AT&T Broadband Xref: archiver1.google.com comp.lang.ada:17487 Date: 2001-12-05T23:59:31+00:00 List-Id: "Ted Dennison" wrote in message news:DpxP7.50285$xS6.83694@www.newsranger.com... > In article , 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