On Sun, 18 Mar 2007 12:10:19 -0000, Ion Gaztañaga <igaztanaga@gmail.com> 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