|
Boost : |
Subject: Re: [boost] Proposal: Monotonic Containers
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-06-10 02:51:03
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk