$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Phil Bouchard (philippe_at_[hidden])
Date: 2008-08-08 03:43:26
"Gordon Woodhull" <gordon_at_[hidden]> wrote in message 
news:EC4056C7-4D91-4591-A2CC-D909A6340FF6_at_woodhull.com...
[...]
> I think we are working on complementary problems having to do with  better 
> ways to manage systems of objects that point to each other.  In  the 
> metagraph library, I am working with fusion and intrusive to build  up 
> objects that are e.g. nodes in graphs and also items in lists and  also 
> nodes in trees, all at the same time.  Really the "is also" is  what 
> intrusive allows and I'm trying to describe these systems better  using 
> metagraph patterns, which are metadata graphs describing object  types 
> ("roles") and the other types they point to or contain  ("relations").
Intrusive node pointers cannot be owners of the object referred to.  If we 
include all the necessary node pointers according to the number of 
containers pointing to the node itself then we could take advantage of all 
the container properties combined at the same time:
struct node : list_node, map_node, vector_node
{
    char c_;
    node(char c = '') : c_(c) {}
    bool operator < ()...
    bool operator == ()...
};
node elements[] = (node *) {'T', 'h', 'i', 's', ' ', 'i', 's', ' ', 'a', ' 
', 't', 'e', 's', 't'};
// e prefix here stands for "explicit":
elist<node> l(element, element + sizeof(elements) / sizeof(* elements));
emap<node> m(element, element + sizeof(elements) / sizeof(* elements));
evector<node> v(element, element + sizeof(elements) / sizeof(* elements));
cout << v[6].c_ << endl;
cout << m.find("a")->c_ << endl;
Here the vector will have to support index fragmentation if we start 
inserting objects between consecutive ones:
(l.begin() ++ ++)->insert('h');
[...]
> What I am trying to understand is that your library seems to be about 
> lifetime management, but then you are also talking about adding all  this 
> cool new functionality to the standard containers.  Do you  anticipate 
> adding new methods to STL containers, or is the "external  access to the 
> nodes" via shifted_ptr itself?  How would you express  the command, 
> "splice this subtree into another container"?
I am already adapting the current Gcc Libstdc++ containers to support smart 
pointers.  All the details related to explicit node access haven't been 
discussed yet but any contributions to this are welcome.
[...]
Bests,
-Phil