From: Daniel James (daniel_james_at_[hidden])
Date: 2006-11-01 15:54:58
John Maddock wrote:
> 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 :-)
You're probably right. I think I've assumed a few things beyond what is
stated in the allocator requirements - mainly because it would be
impractical not to. I don't think it's ever stated that
Allocator::pointer's operations are no throw, but really they must be.
The main reason for my concerns was that for deallocate it's explicitly
said that it does not throw exceptions. But nothing is said for any
other expressions. But then, from a quick look at the requirements, the
meaning of Allocator::address doesn't seem to be defined at all.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk