[Dune] [Dune-Commit] dune-common r5882 - trunk/dune/common

[Oliver Sander]

> but list/set/map might (and will in general) allocate
> mulitple independent memory fractions. So you can not
> use the static_allocator despite you know that the container
> will allocate a fixed number (of unknown size) at once.
>   
No, at least with the implementation on my system you can
keep allocating.  The memory you get is always right after
the memory that is already occupied.  On the other, you
cannot really deallocate at all.
> So one will hardly use this with anything else then vector.
>   
I admit I didn't actually test it, but if it was true I wouldn't
really know what array_allocator is supposed to be good
for at all.

>> This is bit simpler than the gnu array_allocator.  You could then
>> implement ReservedVector using this allocator, much like Carsten
>> suggested.  This would be a very short file, then.
>>     
> That would be much nicer, however you still waste
> memory with the 'pointer to storage' and 'capacity'
> members of std::vector.
>   
That is true, and I think I know that Christian is interested
in small arrays.

I rest my case.  I am not happy with ReservedVector, but I can't
think of the perfect solution either.

Best,
Oliver

> Regards
> Carsten
>
>   
>> Yrs,
>> Oliver
>>
>>
>>     
>>> As you said, you allocate your memory somewhere else. I want something
>>> with the memory inside. Actually your vector doesn't allocate memory
>>> at all.it is only a view on an other array.
>>>
>>> I give you two use cases and perhaps you can tell me how it should
>>> work.
>>>
>>> 1) write something like this:
>>>    
>>>    std::vector< ReservedVector<int,4> > vec;
>>>    for (int i=0; i<n; i++)
>>>      vec.push_back(ReservedVector<int,4>);
>>>
>>>    and assume that the number of elements does vary. How to handle
>>>    dynmic memory memory management with the allocator?
>>>
>>> 2) you store some stuff in std::vector< ReservedVector<int,4> > and
>>>    hand it to the user. Now the user can delete the vector and the
>>>    memory is freed. How so you handle memory-ownership with the
>>>    allocator?
>>>
>>> Perhaps I just don't get it, but I still think that the two approaches
>>> are substatially different.
>>>
>>> Christian
>>>   
>>>       
>>     
>
>
>   


-- 
************************************************************************
* Oliver Sander                ** email: sander at mi.fu-berlin.de        *
* Freie Universität Berlin     ** phone: + 49 (30) 838 75348           *
* Institut für Mathematik      ** URL  : page.mi.fu-berlin.de/~sander  *
* Arnimallee 6                 ** -------------------------------------*
* 14195 Berlin, Germany        ** Member of MATHEON (www.matheon.de)   *
************************************************************************