W dniu 06.05.2011 06:31, Wojciech "Spook" Sura pisze:
> Prawdę mówiąc, w tym przypadku zgadzam się z autorem pierwszego posta.
> Twój przykład nie ma wycieku pamięci jako takiego, tylko nieumiejętne
> zarządzanie tablicą. Jeśli mam tablicę od 0 do 9 i ustalę, że pierwszym
> elementem jest 5, to mimo tego w każdym miejscu programu nadal jestem w
> stanie dostać się do pierwszych czterech elementów. Jeśli napiszę zaś
> funkcję, która zaalokuje pamięć i jej nie zwolni (oraz nigdzie nie
> pozostawi do niej wskaźnika), to w praktyce *nie* jestem w stanie do tej
> pamięci już się dostać.
Alokator sobie gdzieś istnieje, więc MOŻESZ się do niej dostać.
Bezpieczne to nie jest, ale możliwe ;)

> Fir mówi o wyciekach pamięci na poziomie zarządzania pamięcią
> operacyjną, Ty mówisz o "wyciekach" na poziomie logiki programu.
W którymś z postów już napisałem, że ograniczanie się do czystych
"memory leaks" na poziomie systemu operacyjnego jest sztuczne, bo
mechanizm "wycieku" zasobów jest ten sam i dla pamięci, i dla puli
obiektów i dla socketów: w momencie gdy pozbywamy się referencji na
obiekt nie zwalniamy go.

A prawie w każdym systemie musimy mieć dynamiczny przydział zasobów - w
ten czy inny sposób, więc zachwalanie jakiejś metodyki dlatego, że w
niej nie wycieka "czysta pamięć" jest bez sensu, bo błąd tego samego
typu może spowodować wyciek innego zasobu.

> Inaczej: napisz mi taki program (w C++), który używa tylko obiektów
> alokowanych statycznie i zgłosi wyciek pamięci:
Pokazałem kod w którym raz jest alokacja oparta o new/delete a raz
przydział z puli. Reszta kodu jest DOKŁADNIE taka sama. Czy to znaczy,
że w drugiej sytuacji nic nam nie "wyciekło"?
Imo wyciekło, tylko nie "czysta pamięć" a obiekty z puli, ale mechanizm
jest dokładnie ten sam.

--
Pozdrawiam
Michoo