On Jun 10, 2009, at 1:59 AM, Christian Schladetsch wrote:
Hello,
My apologies; I should have been less `succint`.
You are a bit trigger happy sometimes.
auto_buffer is, in fact, related, inasmuch as it also attempts to use the stack for storage.
Ok, so you could use Thorsten's auto_buffer as your storage, which actually would give you, potentially, the best of two worlds (allocation speed and - you seem to push this angle - cache) and dynamic heap beyond that initial segment.
However, boost::monotonic provides an allocator that means that *all* STL containers - and other ones - can use the stack for storage. Or the heap.
NOTE: your "storage_base" is not a base abstraction at all, but a "heap_storage"; having a non-leaf having a concrete but totally different behavior from its leaf child is less than beautiful. Why is the behavior of whether to pick the heap storage ("storage_base"... ugh) or stack (if not embedded in a heap-allocated object...) decided at runtime, via that polymorphic "storage_interface"? It is set at the creation of the allocator, so why not make it a type parameter of the allocator, with a default to, say, "inline_storage"? Do you think it is important to have two containers sharing the exact same type even when one uses "storage_base" and the other "inline_storage"?
In that respect, auto_buffer<T> is a subset of the proposed boost::monotonic::vector<T>.
I still fail to see why you wrap all those containers, instead of providing just that allocator. Is the only reason what I just mentioned, to keep the storage mechanism variable ("storage_base" or "internal_storage") while the container types equal? That is the only somewhat logical rationale for me. Regarding injecting stuff, such as your allocator, in a template class higher up the hierarchy (such as in std::vector), you should have a look at my proposal at a "type injector": http://blog.davber.com/2006/07/24/hierarchy-generation-in-c/ Take care. /David