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=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ce0900b60ca3f616 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-05 11:28:43 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!hub1.nntpserver.com!news-out.spamkiller.net!propagator-la!news-in-la.newsfeeds.com!news-in.superfeed.net!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <3BE29AF4.80804@telepath.com> <3BE29BD4.10401@telepath.com> <3BE2DB99.B707D409@boeing.com> <3BE32A18.18404AD1@boeing.com> <3BE443DE.574D669C@acm.org> <3BE58FDD.E1FB1815@san.rr.com> Subject: Re: List container strawman Message-ID: <4LBF7.13535$xS6.17968@www.newsranger.com> X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Mon, 05 Nov 2001 14:28:00 EST Organization: http://www.newsranger.com Date: Mon, 05 Nov 2001 19:28:00 GMT Xref: archiver1.google.com comp.lang.ada:15833 Date: 2001-11-05T19:28:00+00:00 List-Id: 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.