Re: [boost] Status of Hash Collections?

From: John Maddock (john_at_[hidden])
Date: 2006-11-01 08:22:38

Daniel James wrote:
> On 01/11/06, John Maddock <john_at_[hidden]> wrote:
>> I don't know about address, but you are allowed to assume that all
>> allocators compare equal.  Does that help?
>
> I've been trying to fully support allocators in order to support
> allocators such as the one from Ion's shared memory library. I realise
> that most implementations don't do this so it's probably not vital.
> And it's still an open issue how swap should be implemented:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431
>
> Allocator::address is actually the more important issue, as I use it
> to destruct nodes. If it can throw I really should change the
> implementation so that it doesn't. While I'd prefer not to, it's not
> too bad. I'll have to remove an optimisation for iteration. Also, I'm
> constructing the value in nodes separately from the pointers, in order
> to avoid an extra temporary, but I won't be able to destruct them
> separately. It feels wrong to destruct them in a different manner to
> their construction, but I don't think it'll cause any problems in
> practise.

The thing is I can't really imagine a situation where it would throw: or are 
you thinking of on-disk data structures maybe?

My gut feeling would be to document any limitations and see how it flies: 
you've already gone beyond the requirements of the std, so I guess you could 
mark the use of non-equal allocators as experimental or something.

Basically it sounds like you need some real-world feedback to decide how 
best to proceed?  Getting the containers in Boost would be one way to get 
that experience: as long as the more experimental aspects that go over and 
beyond what TR1 requires are documented I don't see a great problem.  Don't 
forget that someone may come up with either a killer suggestion, or a 
killer-gotcha during review that changes things anyway :-)

HTH, John.