On 14/04/2012 12:36, Sebastian Biały wrote:
> On 2012-04-14 02:54, Andrzej Jarzabek wrote:
>> Ale:
>> * Alokacja na stosie
>
> To nie język funkcyjny żeby było to wygodne. Zdecydowana większość kodu
> pisanego w C++ i Javie działa intensywnie używając heapu.

W Javie zdecydowanie, bo nie da się utworzyć obiektów na stosie.

W C++ nie podejmuję się powiedzieć jak jest z większością, ale na pewno
alokację na stosie wykorzystuje się intensywnie w krytycznych z punktu
widzenia wydajności fragmentach programu. Funkcyjność nie ma nic do
rzeczy, "ciasna pętla" często potrafi nawet w C++ polegać na tym, że się
jakąś wartość skądś uzyskuje (jest zwracana przez funkcję), umieszcza w
zmiennej lokalnej, i przekazuje jako argument do kolejnej funkcji, która
ci zwraca coś, co jest np. dodawane do akumulatora zliczającego sumę w
tej pętli. Wszystko to może się odbywać na stosie (w zależności od
charakteru danych, ale często tak)

>> * Kompozycja
>
> Stoi w sprzeczności z separacją funkcjonalności.

Boponieważ?

> Wyważenie jest cieżkie.
> Wprowadzanie w design od razu optymalizacji na pamięć jest niebezpieczne.

Kompozycja jest w C++ najbardziej naturalna, to inne relacje (przez
wskaźniki czy inne smart pointery) musisz "wprowadzać" ze względu na
cośtam (shared ownership, polimorfizm itd.)

>> * Zamiast zwykłej sterty można stosować poole czy regiony.
>
> Poole czy regiony problem tylko zamieniają na mniejszy, lokalny. Ale
> bedzie dalej występował.

Jeśli dobrze przemyślisz użycie tego, to w praktyce nie będzie.

> Nie piszę o Javie. Chodzi ogólnie o to że C++ nie wymyslił niczego
> najlepszego w dziedzinie zarządzania pamięcią.

Ja pisałem o Javie. A kto wymyślił coś najlepszego w tej dziedzinie?