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-Thread: 103376,f82868bd08967223 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.59.229 with SMTP id c5mr26484697pbr.6.1321349024872; Tue, 15 Nov 2011 01:23:44 -0800 (PST) Path: h5ni56756pba.0!nntp.google.com!news1.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting.com!newshosting.com!87.79.20.101.MISMATCH!newsreader4.netcologne.de!news.netcologne.de!newsfeed.straub-nv.de!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Booch Components question Date: Tue, 15 Nov 2011 09:23:42 +0000 Organization: A noiseless patient Spider Message-ID: References: Mime-Version: 1.0 Injection-Info: mx04.eternal-september.org; posting-host="dFCm8HWntFqmDIilBLqEJQ"; logging-data="24692"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19HUiDXDwBYUAH3eYEOPFoDP19aAtwejnw=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (darwin) Cancel-Lock: sha1:j+eas2NxfAGkCz9vEfSVu3hfyGo= sha1:ehAZt8h0mRkhkAXS60/ck389NIs= Xref: news1.google.com comp.lang.ada:18928 Content-Type: text/plain; charset=us-ascii Date: 2011-11-15T09:23:42+00:00 List-Id: "Dmitry A. Kazakov" writes: > On Mon, 14 Nov 2011 17:18:14 -0600, Randy Brukardt wrote: >> OTOH, the name "list" seems highly confusing. "List" seems to have >> gained a fairly standard meaning in the use of containers, and I'm >> not surprised that most people look there first. Having something >> that works rather differently with that name is asking for trouble. > > Hmm, what do you mean? The BC's list looks pretty much like list to > me. On the surface, yes. But the 'structural sharing' is both hairy and difficult to understand. -- These abstractions have been carefully constructed to eliminate -- all storage leaks, except in the case of intentional -- abuses. When a list is manipulated, all items that become -- unreachable are automatically reclaimed. Furthermore, this -- design protects against dangling references: an item is never -- reclaimed if there exists a reference to it. What about unintentional abuses, I ask! or even just mistakes. -- Unreachable items are those that belong to a list or a sublist -- whose head is not designated by any alias. For example, -- consider the list (A B C), with the head of the list designated -- by L1. L1 initially points to the head of the list, at item -- A. Invoking the member function Tail on L1 now causes L1 to -- point to item B. Because A is now considered unreachable, the -- storage associated with item A is reclaimed; the predecessor of -- B is now null. Similarly, consider the list (D E F), with the -- head of the list designated by both L1 and L2. Both L1 and L2 -- are aliases that initially point to the head of the list at -- item D. Invoking the member function Tail on L1 now causes L1 -- to point to item E; L2 is unaffected. Suppose we now invoke the -- member function clear on L2. The semantics of this operation -- are such that only unreachable items are reclaimed. Thus, the -- storage associated with item D is reclaimed, because it is no -- longer reachable; L2 is now null, and the predecessor of E is -- now null. Items E and F are not reclaimed, because they are -- reachable through L1. Ugh.