Glas List: 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 
heap_storage's).

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 
numerical values.

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,

toon