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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e5327159069b64d5 X-Google-Attributes: gid103376,public From: "news.oxy.com" Subject: Re: Doubly linked list. Date: 1999/01/20 Message-ID: <784c6c$d8s$1@remarQ.com>#1/1 X-Deja-AN: 434765193 References: <7560vn$21e@romeo.logica.co.uk> <781p6h$mlg$1@remarQ.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Complaints-To: newsabuse@remarQ.com X-Trace: 916829196 HXI3FRZSOA57FC7F8C usenet54.supernews.com Organization: Posted via RemarQ, http://www.remarQ.com - Discussions start here! Newsgroups: comp.lang.ada Date: 1999-01-20T00:00:00+00:00 List-Id: Simon, It is a great pleasure for me to hear that I was able to help. What is regarding quote from Bc.Containars.Lists it sounds quite natural for me. Bc implementation of doubly linked lists is a chain of nodes each containing pointers to prev. and next nodes as well as reference to the object denoted by that node (this object may be any kind of object including list, tree ,buffer, queue e.t.c.). Such object may belong to more than one list. Moreover it may belong to any other kind of structure (e.g. tree, list etc.). When applying Clear function to the list it deletes nodes in the chain denoted only by the list to which this function was applied. Any object that is referenced by any node in this particular chain is deleted only if it is not referenced form any other structure to which it may belong. It is also possible that the same object may referenced by the different elements of the same list. This is extremely flexible. Such flexibility is achieved through the use of controlled types. To me this is absolutely right approach. As BC is free software in ADA it is possible to build something more complicated based on it or use it as software patterns which may be easily modified for particular needs. As a matter of fact I am not software engineer. I am radio-electronic system engineer (all kind of systems) so I am doing some programming when I need to do it for some particular purpose and also for my pleasure. If there are some specific question regarding BC you can ask Simon Wright simon@pogner.demon.co.uk ) who is maintaining it. Regards, Vladimir Olensky (Vladimir_Olensky@oxy.com) Telecommunication specialist, Occidental C.I.S. Service, Inc. ( www.oxy.com ) Moscow, Russia. Simon Wright wrote in message ... >"news.oxy.com" writes: > >> Have a look at the ADA95 implementation of the Booch components >> http://www.pogner.demon.co.uk/components/bc/ ). >> Everything is already at hand (including all types of linked lists). Just >> use it. Also this is very good example of ADA95 programming. > >Thanks for that, Vladimir! (from me and the team) > >One small point, which I'm not sure how to address; the BCs have a >perhaps surprising take on manipulating lists. > >The following comment is a direct transliteration of the C++ words >(and it shows in places! "member function" indeed ..): > > -- 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. > >I think this is not in fact that far from a Lisp approach, but at >least one user has been bitten by it (not helped by there being an >effor which meant that parts of the list were sometimes reachable when >they shouldn't have been). > >STk> (define foo '(a b c)) >STk> (define bar foo) >STk> (set! foo (cdr foo)) >STk> foo >(b c) >STk> bar >(a b c) > >Of course, there's no easy equivalent of the doubly-linked list ..