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-09 10:00:50 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!sfo2-feed1.news.digex.net!intermedia!news-out.spamkiller.net!propagator-la!news-in-la.newsfeeds.com!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: 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: Fri, 09 Nov 2001 13:00:03 EST Organization: http://www.newsranger.com Date: Fri, 09 Nov 2001 18:00:03 GMT Xref: archiver1.google.com comp.lang.ada:16151 Date: 2001-11-09T18:00:03+00:00 List-Id: In article , ramatthews@tinuviel.com says... > >In article , Kilgallen@SpamCop.net (Larry Kilgallen) wrote: >> In article <3BE58FDD.E1FB1815@san.rr.com>, Darren New writes: >> >>> If you really want it to be foolproof, >> >> Yes please. > > >While I see a foolproof list does not have universal appeal I have >been successfully using one for some time so I thought its >specification would help discussions. Yup. That does exactly what is needed to make it safe. I never said it was impossible, just that its a lot of work, inculding some extra runtime work that might not endear the facility to real-time users. One problem is that creating an iterator with this facility involves dynamic allocation and linked-list traversal. That violates our general principle of avoiding runtime vs. setup overhead, but that could probably(?) be fixed or at least avoided by the user if noted. Another issue is that it puts a controlled type in the generic package, which I was trying to avoid so that it was instantiateable at lower levels. However, it turned out that List has to be controlled anyway, so perahps this isn't so bad. I'm interested in what the general consensus is here. Should we do the extra work to make iterators safe, given that this will have at least the following effects: o Add extra dynamic memory operations to any list modification (there were some there already). o Add a (usually small) internal list traversal to any element deletion. o Add a small validity check (or possibly two) to every iterator operation. o Possibly make iterator creation non-determistic (time-wise). o Possibly make iterator assignment non-deterministic. Note that functions are currently used for iterating, so that would make just about any use of iterators non-determinstic, unless procedure variants are introduced. If there's a way to get rid of the last two "possibly"s (which there probably is, but I don't know), I think I'd vote in favor of it. Otherwise I'd lean against it just on the basis that I don't generaly go for one small "nice-to-have" feature accounting for large amounts of the implmentation's code and complexity, which is what would happen here. --- 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.