Boost logo

Boost :

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

> 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

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


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