Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk