
Hi Christian, 2009/6/10 Christian Schladetsch <christian.schladetsch@gmail.com>
There is a case for:
boost::monotonic::inline_storage<N> storage; std::vector<int, boost::monotonic::allocator<int> > v(storage); // (A)
versus: boost::monotonic::inline_storage<N> storage; boost::monotonic::vector<int> v(storage); // (B)
but what about: boost::monotonic::inline_storage<N> storage; boost::monotonic::map<int, float> v(storage);
versus: boost::monotonic::inline_storage<N> storage; std::map<int, float, std::less<int>, boost::monotonic::allocator<int> > v(storage);
My main concern would be that people just aren't comfortable with the idea of using custom allocator types, but they will accept the idea of needing to pass the storage in once they realised that they needed a monotonic container.
There are other important issues, like having to give the predicate type for the associative containers first.
If I didn't think it was important, I wouldn't have proposed the library in the first place. Given that I think that it's important, it is also important to me that the usage is clean. (A) above may be `better`, but (B) is cleaner.
I much prefer using a standard template library container to any other, even if it's the same thing but different. I would therefore much prefer the std::map<int, float, std::less<int>, ...> approach to creating another container; especially as this one can also take a different comparison operator. My rationale is that when I want a vector with a different allocation scheme, I like to say "vector with a different allocation scheme" rather than "differently-allocated not-quite-a-std::vector". Kind regards, Peter Bindels