
"Gordon Woodhull" <gordon@woodhull.com> wrote in message news:EC4056C7-4D91-4591-A2CC-D909A6340FF6@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/t... [...]
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