🚀 go-pugleaf

Sektor van Skijlen wrote:

> 
> Innymi słowy, odnoszę wrażenie że autorzy przyjmują milcząco, że tak sprawne
> zarządzanie pamięcią, jakie oferuje nam odśmiecanie jest możliwe tylko wtedy,
> gdy stosujemy "odśmiecany" model zarządzania obiektami, czyli inaczej mówiąc,
> gdy polegamy na niejawnym usuwaniu zgubionych obiektów w przypadku wszystkich
> istniejących obiektów w całym systemie. Przekonanie to jest moim zdaniem
> całkowicie błędne.
> 
> Po pierwsze, zupełnie nie rozumiem, dlaczego takie znów niemożliwe byłoby
> przyjęcie takiej strategii, że środowisko jest takie jakie, jak odśmiecane,
> tylko że nie dokonuje się automatyczne trackowanie obiektów, a jest ono
> uruchamiane dopiero w momencie zrobienia jawnego 'delete'. I to też
> niekoniecznie za każdym, tylko z odpowiednią amortyzacją. Włączając w to
> również możliwość przesuwania obiektów.
Można tak by zrobić. Zostaje tylko pytanie po co. Po to żeby nie 
odśmiecały się obiekty jak ktoś zapomni o delete ?
I wtedy lepiej będzie pisać:
	 new Object().delete(); //żeby środowisko trackowało :-)

> Po drugie, najefektywniejszym sposobem zarządzania pamięcią obiektów,
> szczególnie dużą ilością małych obiektów o krótkim czasie życia, pozostaje
> alokator specjalizowany (pula przeznaczona dla obiektów tylko jednego typu).

Najefektywniejszym w jakim sensie ?
Np. w sesnie zużycia CPU to prawdopodobnie najefektywniejszym jest 
dokupienie kilku terabajtów pamięci i wyłaczenie gc :-)

> To jest też prawda, że odśmiecacz zapobiega wyciekom pamięci
nie
> i zmniejsza
> niebezpieczeństwo istnienia wiszących wskaźników, 
tak
> ale związku z efektywnością
> przydzielania pamięci nie ma to za grosz.

?


> Można by zadać pytanie, dlaczego w takim razie w C++ wciąż stosuje się
> "malloc-based" przydzielanie pamięci (taka jest niestety praktyka, nie tylko w
> gcc). Nie wiem. Może ktoś z grupowiczów mógłby przedstawić jakieś potencjalne
> problemy z zaimplementowaniem takiej metody, jak opisana w p1?

bo to by już nie było C++ tylko Java-- ?

-- 
jarekr