"Gordon Woodhull" <gordon@woodhull.com> wrote in message news:56F3BD3B-DAC3-43B1-96F5-4BB4A3919B10@woodhull.com... [...]
But to get there wouldn't you need to change the public interface of set/map? Right now it won't even admit it's holding a tree. Wouldn't you have to teach it how to reuse nodes rather than creating new ones? I also think there might be overlap issues between an inserted tree and its new siblings. For list, you *might* be able to keep the same interface, but the invariants would be much stranger if one list could modify another.
Well if we could have external access to the nodes themselves we could do a lot. I think this should be a task delegated to iterators. I do not wish to elaborate to much at this time because it is late and I would like demonstrating another useful example. The following doesn't work yet and I found another bug I need to correct but the idea is relatively easy to get. Here's an example on how we could write a "human brain kernel", which is all it basically really is: https://svn.boost.org/svn/boost/sandbox/shifted_ptr/libs/smart_ptr/example/r...
In sum, I'm very interested in these data structures, I just wonder if they might be better served by new classes rather than modifications to STL. Your original application in garbage collection seems valid to me, although I am no allocator expert.
Everybody has their own preferences but personnaly I do not have strong beliefs in new classes. Functional programming is a very powerful option and nesting up these containers would be very extendible I think. But this should be up to the programmer to see his options. Thanks, -Phil