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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.98.24.77 with SMTP id 74mr6059938pfy.8.1466811979764; Fri, 24 Jun 2016 16:46:19 -0700 (PDT) X-Received: by 10.157.45.14 with SMTP id v14mr91614ota.12.1466733325350; Thu, 23 Jun 2016 18:55:25 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!r1no359056ige.0!news-out.google.com!d62ni13418ith.0!nntp.google.com!r1no359032ige.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 23 Jun 2016 18:55:25 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=216.121.226.25; posting-account=ENgozAkAAACH-stq5yXctoDQeZQP2E6J NNTP-Posting-Host: 216.121.226.25 References: <66c14298-c62d-4f4b-b0c0-e969454f9334@googlegroups.com> <2e39857a-7121-476b-807a-d2bff1e598f4@googlegroups.com> <431af616-7df3-4e4d-9262-26ed68cb74c7@googlegroups.com> <037df2b8-b9c4-4447-87ee-cc89d7072b30@googlegroups.com> <15914c54-191c-4f37-b754-282855d1aeaf@googlegroups.com> <3e25c9a0-469c-4487-b78e-6f87434f87fa@googlegroups.com> <2e69ca6f-484c-4d58-b0fe-d17a744b1418@googlegroups.com> <9ada1cdc-2fbd-4009-99f1-aba71ac1b9d2@googlegroups.com> <2954ae98-c4a0-4089-93bc-97854e009785@googlegroups.com> <581cb97c-9d81-4a81-9a05-eed0516ce287@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <687234fb-a16b-4310-8523-5c247a0359d3@googlegroups.com> Subject: Re: Generic Embedded List Nodes From: Warren Injection-Date: Fri, 24 Jun 2016 23:46:19 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:30910 Date: 2016-06-23T18:55:25-07:00 List-Id: On Thursday, 23 June 2016 11:36:25 UTC-4, Niklas Holsti wrote: > On 16-06-23 15:37 , Warren wrote: > > On Thursday, 23 June 2016 04:19:35 UTC-4, Niklas Holsti wrote: > >> On 16-06-23 05:12 , Warren wrote: > >>> On Tuesday, 21 June 2016 17:38:36 UTC-4, Niklas Holsti wrote: > >>> ... > >>>> type Emb_Node_T is tagged; > >>>> > >>>> type Emb_Node_Ref_T is access all Emb_Node_T'Class; > >>>> > >>>> type Emb_Node_T is tagged record > >>>> Prev, Next : Emb_Node_Ref_T; > >>>> -- Prev and Next are null if the node is not in any list. > >>>> -- When the node is first in a list, Prev points to the list = head. > >>>> -- When the node is last in a list, Next is null. > >>>> end record; > >>>> > >>>> subtype List_T is Emb_Node_T; > >>>> -- A list head. > >>>> -- Next points to the first node in the list. > >>>> -- Prev is null. > >>> ... > >>> > >>> The insertion, traversal and deletes are generally no problem. The pr= oblem > >>> occurs when traversing to access the object. > >> > >> Indeed I left out an example of traversal, sorry. > > > > No problem. The other issue is that I need to support at least > > two lists. It gets rather messy when extending the object for > > each additional list, IMO. >=20 > My example had two embedded list nodes in the object, so the object=20 > could be a member of two lists. You can define as many nodes as you=20 > like, in the same record type, at the same time. Ok, I see now (my eyes get bad by end of day after staring at screens all d= ay). I've been thinking today that by using the file descriptor as an index into= a large array (of access to records), I can make this relatively clean in = Ada. The array would not only act as a lookup for the event structures, but= serve as a cache of such. I never really need to release them. If I did want to reclaim any, I could start at the high end of the array, s= ince those will be used under heaviest use. This is one of the nice feature= s of the Unix kernel- open files always have the lowest available unit numb= ers assigned. Warren