Daniel James wrote:
On 01/11/06, John Maddock <john@johnmaddock.co.uk> 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.