Boost logo

Boost :

From: Phil Bouchard (philippe_at_[hidden])
Date: 2008-08-06 05:50:38

"Gordon Woodhull" <gordon_at_[hidden]> wrote in message


> 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:

> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at