Re: [boost] [shifted_ptr] STL support: 99%

From: Phil Bouchard (philippe_at_[hidden])
Date: 2008-08-07 07:19:54

"Gordon Woodhull" <gordon_at_[hidden]> wrote in message 
news:EC4056C7-4D91-4591-A2CC-D909A6340FF6_at_woodhull.com...

[...]

> Do you mean, there would be special iterator types that mean "reuse  these 
> nodes" instead of "copy these"?  Or do you have some other way  of 
> preserving the public interface of e.g. std::set while adding the  shared 
> node functionality?

I think having classes derived from nodes would be a great idea.  I have 
improved the example I submitted yesterday with a new one.  I haven't fixed 
the run time bug yet but once again the code is fairly easy to understand. 
I added some code making our brain learning and I am using a global map 
pointing to the neurons themselves.  This is a great example in this 
scenario adn we can see how we could benefit from these nodes.  Imagine the 
map uses our class called "map_node" as a template parameter for example. 
We could explicitly attach neurons with nodes and not suffering from all 
these temporary little nodes having pointer to neuron as data members we 
currently have.  This way the map will refer to the same object allocated on 
the heap.

Let's take a look at the following file:
https://svn.boost.org/svn/boost/sandbox/shifted_ptr/libs/smart_ptr/example/t100.h

[...]

> I haven't really considered ownership or GC (don't need it for my app, 
> Dynagraph), so I imagine your techniques (or hopefully, library) could  be 
> useful for people with metagraphs who want automatic lifetime  management.

Just for the record... I am not using garbage collection at all.  Nothing is 
being collected and no periodic system slowdown is required.

[...]

> If I understand correctly, it's a kind of neural net and shifted_ptr 
> would delete regions when they become detached?

Precisely, just disregard that deallocation problem and expect objects being 
destructed in real time.

[...]

> Agnostic here - whatever works best.  I was assuming that you would  have 
> to make massive changes to the public interfaces of the STL  containers; 
> now I am not so sure that is true.

No, we can see some of them in the following sample patch file:
https://svn.boost.org/svn/boost/sandbox/shifted_ptr/bits/stl_list.h.patch

[...]

> 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"?

The first file I was previously refering to is an example of what I think 
would fit best; i.e. by defining our own nodes and using them as a container 
template parameter.  "splice this subtree into another container" is exactly 
what I am looking for and I am very interested into searching only part of a 
tree, not the entire tree.  Maybe by creating a new map constructor defining 
the beginning and the end of the new map using iterators, but in contrast to 
the actual one we don't want to duplicate the nodes.  It should therefore be 
reasonnably fast.

> If your library reflects a system of objects at runtime so that any 
> pointers between them are traversable, then I think there might some 
> interesting synergy with what I'm working on, which is about  describing 
> pointers between types at compile time.

I am not sure what you are referring to but hopefully you have a better 
overview of what it actually is and where it is going.  STL support for 
smart pointers is imminent.

Bests,
-Phil