|
|
Glas :Re: [glas] introducing the storage concept, a first interface specification |
From: David Abrahams (dave_at_[hidden])
Date: 2005-01-18 08:14:26
Toon Knapen <toon.knapen_at_[hidden]> writes:
> Patrick Kowalzick wrote:
>> Dear Toon,
>> I hope I do not miss the point, but I do not really get the reason
>> why to distinguish so many storage_types (heap/stack/disk/...). So I
>> try to summarize what I understood (but as well regarding matrices
>> and only dense cases):
>> To make algorithms work, we need only a very slim interface for
>> cointainers with constructors, element access and size
>> functions. But to make the functions efficient and fast we need more
>> information.
>> IMO the most important points for the storage concepts are:
>> 1.) How are the elements stored ?
>> 2.) How is the data initialized ?
>> 3.) Is the vector resizable ?
>> to 1.)
>> For an effective algorithm it is not necessary that the data is
>> "globaly" consecutive. It might be enough that parts of the data are
>> "localy" consecutive. E.g. two matrices which are stored in several
>> vectors (rows or columns) can be added very fast iterating along the
>> vectors but not across the vectors (but only due to the cache).
>
>
> True. That was also (part of) the idea behind compound_storage. But
> suppose your matrix uses several vectors to store its elements, you
> still want to define _where_ these vectors are stored.
>
> For maximum flexibility you might want to store them on the heap (this
> would allow resizing, see later). But for performance reasons you might
> want them on the stack. This is less flexible however because the size
> is limited.
That's not a question of physical location but of capability. It's
perfectly possible and reasonable to have fixed-size vectors on the
heap.
I don't understand why you're reinventing the matrix concept taxonomy
when MTL basically got it right to begin with.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com