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 autolearn=ham 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-03 11:22:15 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!lsanca1-snf1!news.gtei.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Message-ID: <3BE443DE.574D669C@acm.org> From: Jeffrey Carter X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: List container strawman References: <3BE29AF4.80804@telepath.com> <3BE29BD4.10401@telepath.com> <3BE2DB99.B707D409@boeing.com> <3BE32A18.18404AD1@boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 03 Nov 2001 19:22:14 GMT NNTP-Posting-Host: 209.86.204.110 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 1004815334 209.86.204.110 (Sat, 03 Nov 2001 11:22:14 PST) NNTP-Posting-Date: Sat, 03 Nov 2001 11:22:14 PST Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Sat, 03 Nov 2001 11:18:16 PST (newsmaster1.prod.itd.earthlink.net) Xref: archiver1.google.com comp.lang.ada:15746 Date: 2001-11-03T19:22:14+00:00 List-Id: Ted Dennison wrote: > > In article <3BE32A18.18404AD1@boeing.com>, Jeffrey Carter says... > >The technique used by PragmARC.List_Unbounded_Unprotected is that the > >list object contains a pointer to a "mini-node" (a node with no data > >stored in it). This makes insertions and deletions at the beginning and > >end of the list look exactly the same as insertions and deletions in the > >middle, but it also follows that the value of this pointer is unique to > >the list object. Call this value the list ID. Every node in the list > >contains a copy of this ID, as does every Position value generated for > >the list. An operation is not permitted unless the IDs for the list, > >position, and node match. When a node is deleted, its ID is invalidated > >(set to null), and the position used to delete the node is similarly > >invalidated (both its ID and pointer are set to null). If a client makes > >a copy of a Position and uses one to delete a node, he cannot then > >manipulate the deallocated node through the other since it has an > >invalid ID. Easy to implement and fairly foolproof. > > So you are saying that you are placing values into the memory before it is > deallocated, in the hopes that any code trying to access it through a stale > pointer will still find that value there (telling it not to use this)? That's right. You don't get 100% confidence, but it's better than the nothing that most lists provide. > > What if: > a) The memory at that location gets reallocated to something else in the > meantime, which then puts what looks like a valid value in there. It's certainly possible that the memory could be reallocated to the same list, so the dangling reference becomes valid again. I did say *fairly* foolproof. :) > > b) The OS marks that location as not allocated, and issues a segfault (or > whatever) when you try to access it. Then you're no worse off than without the check. > That could be done. "Delete" would also be a natural name for toasting a list, > but then I guess in the current scheme "-" would make more sense for that. Let me record my vote against unary operators as primary names. I probably won't object if they're renames of other subprograms. I suggest Clear for deleting all Elements in a List; Make_Empty might also be acceptable. Finally, what you're calling an iterator is what is usually called a "position within a list" in discussing lists as an abstraction, and the manipulation of a list is usually defined in terms of positions. I think it would make the package easier to understand if it adheres to this convention: call the type Position and present the operations for obtaining positions and using them to manipulate a list before the dequeue- and string-like operations. -- Jeff Carter "I fart in your general direction." Monty Python & the Holy Grail