Re: [boost] Ion Gaztañaga's Intrusive Library

From: Daniel James (daniel_james_at_[hidden])
Date: 2007-03-18 11:18:04

On Sun, 18 Mar 2007 12:10:19 -0000, Ion Gaztañaga <igaztanaga_at_[hidden]>  
wrote:
> Although I haven't seen any useful uses of address()

IIRC the original use case was for segmented memory - the allocator would  
store the segment which would be stored with the pointer in the pointer  
object. Although, I don't really know what I'm talking about here so,  
hopefully, someone will correct me if I'm wrong. And if I'm right, I don't  
think anyone ever actually did this, or ever will.

I'm actually suprised that you're not using it in Boost.Interprocess - I  
assumed you would store the location of the mapped memory in the allocator  
and then in address you'd calculate the offset. I didn't realise that  
offset_ptr was the offset from the actual pointer.

> I agree that I could offer the possibility to
> store an object with address() and other related functions. But
> internally i need more than that because I also need a way to implement
> static_cast and const_cast for non-raw pointer. Currently I'm doing this
> converting the smart pointer to a raw pointer, doing the conversion, and
> going back.

I'm doing the same in the unordered containers. I think the current  
version in the vault has been written to have no casts, but I'm not very  
happy with the technique I used to do this, so I'll probably switch back.

> Another possibility is that the object I allow to be contained inside
> the intrusive container could have both allocator and casting functions.
> In general, current allocator approach is lacking in both pointer
> conversion and placement construction issues.

Yeah, my main motivation for supporting a pretty strict interpretation of  
the allocator interface was Boost.Interprocess, and since that doesn't  
seem to require it, maybe it isn't that important.

> I the standard requires that containers should have no throwing move
> operations (which would be really nice), then we have a big problem with
> allocators.

I'm not really familiar with the move proposal, but having to allocate the  
end node would probably be unacceptable to most - so I think it's fair to  
ignore that requirement.

[snip]
> Another question: would you make irbtree and
> ihashtable implementation classes public?

I was actually going to comment on this kind of thing in my review proper.  
But my answer is: not yet, maybe not at all. I'm not sure how useful  
ihashtable would be - it's tied closely to the STL requirements, so I  
can't see any advantage to using it instead of  
iunordered_set/iunordered_multiset. I'll look more closely at irbtree  
later.

I was also thinking that it might be nice to have simple, lower level,  
structures like binary trees (or n-ary trees for that matter) and circular  
lists, which wouldn't require a container object, just a pointer to a  
node. Again, I'm not sure about this.

> I'm really think that if I can make Intrusive a good tool to implement
> standard containers, that would mean that the library is complete a good
> enough for any task.

I think I'll try creating a simple unordered_set implementation and see  
how it plays with my unit tests (probably not in time for the end of  
review I'm afraid).

Daniel