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:
> 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
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 :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk