Christian Schladetsch skrev:
Hi Peter,
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.
Yes, but what about
boost::monotonic::inline_storage<N> storage; std::map<int, float, std::less<int>, boost::monotonic::allocator<int> > v(boost::monotonic::allocator<int>(storage));
versus:
boost::monotonic::inline_storage<N> storage; boost::monotonic::map<int, float> v(storage);
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".
I grok that; but boost::monotonic::container also is-a std::container with guranteed no extra junk. They are absolutely %100 type-compatible after creation.
I think it is slightly wrong of you to put so much emphaisis on syntactical convinience. In general, such is nice, but your library should offer some more real value. Especially since most containers end up being typedefs so you can easily switch to another, and so nested types are easy to type, and so that you can give better fitting names to your types for a given task. Locality of reference seems like an important problem to improve. I don't agree with those that say high-performance applications usually involves a single container; mine certainly doesn't. Intrusive containers seems to give similar benefits w.r.t. locality of reference. Similar for flat_set/flat_map. It is not clear to me in which niche your library would fit. I hope you can make that clear, and provide examples that show your library performs better than otherwise. -Thorsten