Re: [glas] introducing the storage concept, a first interface specification
From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2005-01-18 05:49:08
Vladimir Prus wrote:
> Some preliminary comments:
> In http://www.femtown.org/glas/doc/storage_array_concept.html
> there's a mention of consecutive_in_memory type, but no semantic is given.
> It's mentioned elsewhere, but I think this should be specified in definiton
> of StorageArray too. Like,
> "if equal to mpl::true_, then all elements are stored consequtively
> starting with &*x.begin()"
You're right. I modified the text as suggested.
(I will update the on-line doc however not yet the .zip and .tgz
packages (because of the overhead))
> In http://www.femtown.org/glas/doc/storage_compound_concept.html you have
> "Default fill constructor". Is it required to fill the storage with
> value_type()? You also have "element access". Those two items is the only
> thing that's changed from StorageArray. Then, I don't understand how, say,
> "element access" is related to the description, which talks about distributed
> storage and groups. Am I missing something?
Well the StorageCompound concept is certainly not complete yet (and
therefore I did not mention it (yet) in my mail). Before going into the
details of the StorageCompound concept I find it important that we have
general agreement on the Storage concept in general.
But since you've mentioned it, a CompoundStorage is actually a storage
containing storages. Thus actually indeed it _is_ a storage, only it's
value_type is a storage instead of a double or int or soth. But of
course this could also be true for a storage that is not a
CompoundStorage (nothing prevents to create a heap_storage of
So as far as operations are concerned actually you are right. The
elemens access and the fill constructor do not make more sense for
compound type of storages in respect to the regular storage.
Maybe the most important (and the only diffence) is that compound
storages would define an embedded type 'is_compound_type' for instance
(that would be boost::mpl::true_ or boost::mpl::false_). This info can
then be exploited to know if dereferencing an iterator would give you
another storage (and thus you can call begin() and end() on it) or your
So coming to think of it more, it's probably better to add this
'is_compound_type' just like we have now the 'consecutive_in_memory'. Do
you agree ?
> The heap_storage container has this declaration:
> template < typename T, typename Alloc = std::allocator< T > >
> class heap_storage
> Is the 'Alloc' parameter needed for something specific, or added just in case.
> I must admit I don't know about any use for 'allocator' parameter in STL at
> all, so I wonder if it's needed in this specific case.
Well the heap_storage needs to allocate memory on the heap anyway (by
definition). So I think it's advised to pass through an allocator that
can be user-tuned. For instance this allows to use an allocator that
allocates from a memory-pool.
thanks for your comments,