🚀 go-pugleaf

Dnia Thu, 6 Apr 2006 09:26:40 +0200, Jedrzej Dudkiewicz skrobie:
> Chodziło mi o to, że jeżeli jest GC, to nie ma ręcznej gospodarki pamięcią.
> Jeżeli nie ma ręcznej gospodarki pamięcią, to nie może powstać wyciek, bo,
> rozumowałem, żeby powstał, to w takim C albo C++ trzeba pamięć z palca
> przydzielić, potem jej poużywać (albo i nie), a następnie przestać zwracać
> na nią uwagę, tj. zlikwidować wszelkie odwołania do niej bez kasowania jej.

Zlikwidować obiekty, lub nadpisać wskaźniki, które ją trzymały.

Poza tym, lekko przesadzasz. "Wszelkie odwołania" to znaczy, że było ich twoim
zdaniem wiele. Tymczasem obiekty współdzielone to rzadkość. Co więcej,
współdzielenie obiektów poprzez trzymanie do nich kilku referencji to bardzo
niebezpieczna technika programowania. GC załatwia ci tutaj problem usunięcia
obiektu i pozostawienia wskaźnika wiszącym, ale nie załatwi ci problemu
tożsamości obiektów. Znacznie sensowniej jest pozostawić jakiejś klasie opiekę
nad tym obiektem i dać jej metodę, która zwróci wskaźnik/referencję do niej.
Wtedy mamy pewność, że zawsze mamy do czynienia z tym obiektem, co trzeba.

> Swoją drogą "nieużywane referencje leżące na dnie kontenera" jakoś nie
> pasują mi do wycieków, bardziej do nieuważnej gospodarki obiektami. Różnica
> jest taka, że taką nieużywaną referencję możemy jeszcze kiedyś przypadkiem
> zwolnić a pamięć, która wyciekła, jest stracona "na wieki".

Nie rozumiem. Dlaczego?

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"