🚀 go-pugleaf

Dnia 2007-11-10, Piotr Wyderski napisał:
> Łukasz Krotowski wrote:
>
>> Ale przecież cały czas rozmawiamy o różnicach alokacji
>> dynamicznej w stosunku do alokacji stosu. W takim
>> przypadku porządek jest zapewniony.
>
> Ale alokator tego nie wie. Sam wektor również nie zna kontekstu,
> w jakim jest używany, więc nie może poinformować o nim alokatora
> nawet, gdyby to było w jakiś sposób możliwe.

Programista to wie i może użyć vector<T, stack_allocator> lub
vector<T>. 

>> Choć z drugiej strony, jeśli porównujemy z tablicami na
>> stosie powinniśmy wyłączyć możliwość zmiany rozmiaru.
>
> Sprzeciw, ja chcę mieć obiekt tymczasowy, dynamiczny i bardzo
> wydajny. Gdybym potrzebował tablicy statycznej, to mam boost::array.
>
>> Niemniej jednak, dedykowany alokator dla obiektów o krótkim czasie życia
>> mógłby zapewnić alokację o wydajności porównywalnej do stosu.
>
> Nie, bo dla alokatora nie długość życia obiektu ma znaczenie, lecz
> porządek destrukcji. Ten porządek nie jest znany i dlatego nie można
> robić założeń na jego temat. Oczywiście, szybki alokator do obiektów
> o krótkim czasie życia może być jedynie kilkadziesiąt razy wolniejszy
> niż alokacja stosowa, ale nie znając kolejności destrukcji to nie jest
> szybki alokator do obiektów tymczasowych, lecz po prostu szybki
> alokator uniwersalny.

Serio, serio?
#v+
// gdzieś, lokalnie w kodzie
memory_pool local_pool(LOCAL_POOL_SIZE);
do_not_deallocate_allocator::set_pool(local_pool);

typedef std::vector<int, do_not_deallocate_allocator> local_int_vector_t;
local_int_vector_t vec1;
// ...
// po zakończeniu pracy
// explicite, równie dobrze może być RAII
local_pool.release();
#v-

W takim przypadku alokacja będzie porównywalna ze stosową, a dealokacja
szybsza. Oczywiście długość życia obiektów ma znaczenie (chyba, że masz
wyznaczoną funkcję zajętości pamięci dla całego programu, wtedy w ogóle
nie musisz martwić się o zwalnianie -- o ile tylko pamięci fizycznej
starczy).

> A jeśli zakładasz porządek LIFO i alokator ma
> tego świadomość, to to nie będzie konstrukcja porównywalna do
> stosu, tylko stos we własnej osobie, istniejący niezależnie duplikat
> systemowej struktury danych. Można się więc takiego alokatora
> bez żalu pozbyć i koncepcyjnie zintegrować ze strukturą danych.

Kwestia podejścia, dla mnie oddzielenie mechanizmu przydziału pamięci od
kontenera przechowującego obiekty jest dobrym pomysłem.

-- 
Łukasz Krotowski | lukasz.krotowski_AT_gmail.com