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

From: Gordon Woodhull (gordon_at_[hidden])
Date: 2008-08-06 21:49:38

On Aug 6, 2008, at 5:50 AM, Phil Bouchard wrote:
> Well if we could have external access to the nodes themselves we  
> could do a
> lot.

Absolutely, I think that would be wonderful.

> I think this should be a task delegated to iterators.

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 we are working on complementary problems having to do with  
better ways to manage systems of objects that point to each other.  In  
the metagraph library, I am working with fusion and intrusive to build  
up objects that are e.g. nodes in graphs and also items in lists and  
also nodes in trees, all at the same time.  Really the "is also" is  
what intrusive allows and I'm trying to describe these systems better  
using metagraph patterns, which are metadata graphs describing object  
types ("roles") and the other types they point to or contain  
("relations").

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.

> 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/regex_test1.cpp

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

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

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.

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

I think I agree.

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

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.

Thanks,
Gordon