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

[Carsten Gräser]

Am 03.02.2010 23:35, schrieb 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.
This requires that the allocator also stores a pointer
to the next unused memory (more wasted memory).

Then you also must ensure that the vector does
not allocate less then the maximal memory.
But this should be possible by always calling
the base constructor with size=maxSize and
then resizing the vector to the desired size.

However you then call the possibly non-trivial
constructor/destructor multiple times even if
you create an empty vector.

Best,
Carsten
>> 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
>>>>   
>>>>       
>>>     
>>
>>
>>   
> 
> 


-- 
----------------------------------------------------------------------
Carsten Gräser           | phone: +49-30 / 838-75349
Freie Universität Berlin | fax  : +49-30 / 838-54977
Institut für Mathematik  | email: graeser at math.fu-berlin.de
Arnimallee 6             |
14195 Berlin, Germany    | URL  : http://page.mi.fu-berlin.de/graeser
----------------------------------------------------------------------