Re: Generic Embedded List Nodes

[Warren <ve3wwg@gmail.com>]

On Sunday, 19 June 2016 15:04:05 UTC-4, Dmitry A. Kazakov  wrote:
> Maybe I don't understand the problem, but it seems you want externally 
> linked objects that themselves were of any type. 

Close, but not quite. I had been toying with the idea that each node point back to the containing object, but I've dropped that clumsy idea now.

Now I am back to the original C idea of converting a Node reference back to its containing object through pointer arithmetic (I know: Ada fans gasping). In short, given a Node, I need to get its containing Object.

> The best way to do it is IMO a custom memory pool.

The problem I have with that is performance. For example deleting a node from a list. 

procedure Delete
          (  Brand     : List_Identification_Type;
             Container : in out Web;
             Element   : in out Node
          );

To delete the node, in the worst case, requires traversing the entire list. My lists can be 30,000+ long.

In the embedded node case, I already have direct access to the affected link node. To remove the node from a list I simply say:

    R.Link_Node.Unlink;

and it removes itself out of the doubly linked list (else does nothing if not already in a list).

I have considered a memory pool and not ruled it out. 

Presently I have an generic Object_Of(Node) function working, which makes use of System.Storage_Elements."+" (gasp!) The only drawback is that I need a fake instance of the Object to determine Node'Position at startup. 

Warren