From: Phil Bouchard (philippe_at_[hidden])
Date: 2008-08-07 07:19:54
"Gordon Woodhull" <gordon_at_[hidden]> wrote in message
> 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
Let's take a look at the following file:
> 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:
> 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
> 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.