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