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.28.197.196 with SMTP id v187mr709259wmf.3.1466302547227;
        Sat, 18 Jun 2016 19:15:47 -0700 (PDT)
X-Received: by 10.157.41.105 with SMTP id d96mr293941otb.19.1466302547063;
 Sat, 18 Jun 2016 19:15:47 -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!goblin3!goblin1!goblin.stu.neva.ru!w10no2736496lbo.0!news-out.google.com!di11ni28891lbb.1!nntp.google.com!w10no2736491lbo.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Sat, 18 Jun 2016 19:15:46 -0700 (PDT)
In-Reply-To: <nk4m5c$oub$1@dont-email.me>
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>
 <nk4m5c$oub$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <e93ab081-708d-4195-98e4-3e58a7cc31d4@googlegroups.com>
Subject: Re: Generic Embedded List Nodes
From: Warren <ve3wwg@gmail.com>
Injection-Date: Sun, 19 Jun 2016 02:15:47 +0000
Content-Type: text/plain; charset=UTF-8
Xref: news.eternal-september.org comp.lang.ada:30802
Date: 2016-06-18T19:15:46-07:00
List-Id: <comp.lang.ada>

On Saturday, 18 June 2016 19:40:31 UTC-4, Jeffrey R. Carter  wrote:
> On 06/18/2016 03:52 PM, Warren wrote:
> > 
> > The idea is that the list node resides within the structure/tagged type,
> > and acts as a doubly linked list node when in a list. The Emb_Node can
> > be used as a list head when itself (or as part of another structure). This
> > kind of thing is done in the Linux kernel, for example.
> >    
> > The Emb_Node and its operations are trivial. The problem occurs when
> > you traverse a linked list of Emb_Nodes (or its derived type). With
> > a given node, I need to then access the object that _contains_ it. In
> > C/C++ you do some offset calculation from the node address back to
> > the owning struct/class.
> 
> Let me make sure I understand this. You have type Emb_Node, and you can string
> Emb_Nodes together to make a list. 

Yes.

> You want to make a composite type with an
> Emb_Node component:
> 
> type Outer is record
>    ...
>    Node : Emb_Node;
>    ...
> end record;

Yes.

> and declare objects of this type:
> 
> O1 : Outer;
> O2 : Outer;

Yes.

>From this point, we add "heads of lists". They can be stand alone, or part of another object (for now let's assume stand alone ):

Timeouts: Emb_Node;

Timeouts.Insert_Head(O1);
Timeouts.Insert_Head(O2);

etc.

Then if you did:

 O1.Node.Unlink; 

the object O1 becomes removed from the linked list it was in (if any).

> and then be able to string the Node components of all these Outers together into
> a list, and then treat that list as a list of Outers.
> 
> Is that correct?

Essentially, yes.  

With one or more Head nodes, you create one or more lists.

Not all of the members need be in any list. Obviously, with only one
given embedded node, that node can be a member of at most one list.

Of course more lists can be supported by adding additional 
embedded nodes, but clearly one needs to be careful not to mix them
up.

Warren