Čišćenje objekata?

Ovo pitanje postavljam iz čiste radoznalosti, jer nikad nisam radio u Delphi-ju.

Kako se vrši oslobađanje memorije u objektnom paskalu? Da li je garbage-collected kao Java i C#, ili reference-counted kao VB6 ili mora "ručno" kao C++ ?

Potpis

IOCC

Ako ima ownera, on to radi. Ako ga nema, morаš ručno i to



Ako ne uradiš free u toku rada aplikacije, ostaju u memoriji do kraja izvršavanja. Tada se automatski free-uju.

Znači, moguće je da dođe do "curenja memorije" i u Delphi programima ako sam dobro razumeo.

A da li postoji pojam "destruktora", tj funkcije koja se automatski pozove kad se objekat uništi?

Potpis

IOCC

pa nije moguce da dodje zbog curenja, jer se svi kreirani objekti, koji nisu oslobodjeni, oslobadjaju na kraju izvrsavanja aplikacije.

to mu sve dodje kao neki hibrid garbage-collecting-a i c++ prilaza. postoje i destruktori, i moguce je oslobadjati okupiranu memoriju u toku rada (za kriticne delove koji mnogo trose memoriju), a moguce je jednostavno napraviti dva-tri objekta, i zaboraviti na njih...


inace, ovo sto je gojko pomenuo ne vazi bash za sve objekte. to vazi samo za komponente (naslednici tComponent), kojima se pri kreairanju obavezno prosledjuje Parent:



ovde je self, isto sto i this u c++/java, a inace pretstavlja formu.

kada se ovako kreira komponenta, nju automatski oslobadja vlasnik (owner) tj forma u svom destructoru..

Potpis

blogče :: unescaped beta
^{» go-paste extenzija
　 » reč dana: backup
　 » bočne koalicije}

Bojim se da se ne razumemo najbolje. "Curenje memorije" je kada program samo stvara nove objekte, a ne oslobađa ih, pa ako radi dovoljno dugo (server-side aplikacije su najčešći primer) onda "pojede" svu raspoloživu memoriju i "crkne". Kad se završi aplikacija, onda OS počisti memoriju nezavisno od programskog jezika, ali poenta je upravo u tome da količina memorije koju proces koristi ne raste "u beskonačnost" čak i ako program radi neprekidno. Kod C++ a moraš sam da vodiš računa da se to ne desi (mada postoje tehnike da se oslobađanje memorije automatizuje), a recimo u Javi možeš da praviš nove objekte do mile volje - GC će da ih pokupi kad primeti da je proces "pojeo" previše memorije. Koliko razumem, Objektni paskal je u tom pogledu sličniji C++u?

Potpis

IOCC

U pogledu objektne orientiranosti,
t.e. construktore, destruktore i slicno,
Objektni Pascal je samo plagijat C++ (bez multiple inheritance)

Tata je sasvim u pravu, da je moguce doci do curenje memorije.

Kada se bilo kom objektu pri alokacije na heap-u postavi owner,
i kad se owner oslobodi, onda njegov destruktor automatski pozove destruktor
svih objekta kojih poseduje. Ali ovo nije svojstvo Objektnog Pascala, vec VCL-a.

Svaka klasa koja nije naslegjena iz neke VCL klase, mora se rucno osloboditi,
kao i svaka VCL klasa kreirana na heap-u ciji je owner nil(NULL)

Potpis

People who think they know everything tend to irritate those of us who do.

Ovo sto pricas da se sve pocisti, ne pije vodu bar za VB i DirectShow objekte (ako ih ne ubijes "rucno"), a i za jos po nesto, ne secam se tacno.

I sta se desi sa tim objektima koje GC pokupi i kako on odredi sta da odabere za ubijanje?

Off topic :
Kako alocirati defragmentirani segment memorije u VB-u ili C++-u?

Potpis

fire, walk with me

Riste, hvala na objašnjenju. Milo mi je da vidim da bar još jedan OO jezik osim C++a ima mogućnost determinističke finalizacije (tačno znaš kad objekat bude počišćen).



Nikad nisam radio sa DirectShow, ali jedno znam: ako "ubiješ" proces, on više ne zauzima memoriju. To nema veze sa programskim jezicima, već je svojstvo operativnog sistema.



GC "pregleda" sve objekte koji su stvoreni i odredi koji se više ne koristi (ni jedan pointer ne pokazuje na njega) pa ga "počisti" a memoriju koju je zauzimao kasnije mogu zauzeti novi objekti.

Inače, VB za to koristi "reference counting". Svaki objekat sadrži i broj pointera koji pokazuju na njega i kad taj broj padne na nulu, objekat se automatski počisti. Meni se "reference counting" više dopada nego klasičan GC, ali to je valjda stvar ukusa.



Ne razumem pitanje.

Potpis

IOCC

ja sam mislio da je curenje memorije, memorija koja ostane zauzeta posle prestanka rada programa..

inace, rekao sam u toku rada programa da se moraju EXplicitno free-ovati objekti..


inace, ja sam u TIJ2 procitao da postoje garbage kolektori za delphi, i (ako se ne varam) za c++, koji se mogu dodati kao utility klase/biblioteke. jel ovo tacno? jel se neko igrao sa nekim? koja su iskustva?


a sto se reference counting-a tice, to je samo jedan od nacina "skupljanja djubreta".. i nije stvar ukusa, vec performansi (koji je nacin za sta pogodniji..). php recimo koristi takodje reference counting, a u javi, zavisi od implementacije JVM-a, mada najcesce se koriste adaptivni metodi (oni koji menjaju u toku rada svoj mod, zavisno od uslova), i to najcesce izmedju stop-and-copy i mark-and-sweep metoda. (reference counting se ne koristi valjda ni u jednoj imlementaciji JVM).

Potpis

blogče :: unescaped beta
^{» go-paste extenzija
　 » reč dana: backup
　 » bočne koalicije}

Za C++ definitivno postoje GC implementacije, a još češće se koriste "pametni pointeri" koji sadrže reference counting (kod mene na poslu, npr).

Za primer GC-a za C++ pogledajte recimo

http://www.codeproject.com/cpp/gc.asp

Što se Delphi-ja tiče, mogu jedino da konsultujem Google:

http://www.delphi32.com/vcl/2736/


Reference counting, za razliku od GC-a omogućava determinističku finalizaciju objekata (tačno znaš kad će objekt da bude unušten), ali uvodi rizik od pojave "cirkularnih referenci", što neki smatraju velikim nedostatkom mada lično mislim da preteruju.

Potpis

IOCC

josh jednom: Reference Counting je VRSTA garbage collecting-a.


a ja zaboravih, i delphi ima reference counting.

kada gode se definise varijabla tipa Interface, i dodeli joj se kreirani objekat, ona radi reference counting...

Potpis

blogče :: unescaped beta
^{» go-paste extenzija
　 » reč dana: backup
　 » bočne koalicije}

Osim tebe, znam samo još jednog čoveka koji tako misli (doduše, stvarno je programer - prva liga):

http://www.boost.org/people/william_kempf.htm

Međutim, većina (uključujući i moju malenkost) reference counting ne svrstava u garbage collection.

Potpis

IOCC

a ja nisam programer? ;)

elem, dobar komentar (prva liga ;)


elem, ajde ti lepo napisi ovde tvoju definiciju GC-a (ili ciju vec hoces) i onda proveri da li vazi i za RC. (moja se uklapa).


inace, ja znam za (najmanje) josh jednog,

Bruce Eckel - Thinking In Java 2^nd edition, Chapter 4 - Initialization and Cleanup - page 137/138


ne znam koliko je dobar programer, ali koliko znam, TIJ, i 2 TIC++ knjige su mu veoma popularne, i smatraju ih medju najboljima (bar znam za TIJ)


i btw, da te pitam, jer mu je i Thinking in C++ tako dobra / popularna kao i TIJ (a zanima me i ona starija njegova o c-u).

znaci, da li si si cuo nesto o njoj (njima), citao, i da li preporucujesh?

Potpis

blogče :: unescaped beta
^{» go-paste extenzija
　 » reč dana: backup
　 » bočne koalicije}

Dobro, verovatno si u pravu - ima ih još koji smatraju da je RC forma GC-a. U izvesnom smislu ste u pravu - i jedno i drugo su forma automatskog upravljanja memorijom, međutim između RC-a i (ostalih formi) GC-a postoji jedna suštinska razlika: RC omogućava determinističku finalizaciju objekata. Drugim rečima, čim broj referenci padne na nulu, objekat se briše. Doduše postoje i neke varijante "odloženog RC-a" i to je bez sumnje GC.

Kad kažeš "đubretar", nekako očekuješ da on sačeka da se đubre nakupi, pa onda dođe i pokupi ga. RC ne radi tako, već svaki objekat ima mehanizam za samouništenje čim postane nepotreban, pa se tu nikakvo "đubre" i ne skuplja. Više puta sam učestvovao u raspravama "GC vs RC" i nekako sam navikao da razlikujem ta dva pojma.

Što se Eckela tiče, čitao sam obe njegove knjige (sad sprema i treću za C#) a za Javu mi je bio primarni udžbenik. Šta znam, nije loš, ali u principu ja ne volim kada pisac pretovara tekst velikim količinama koda. Stroustrup recimo pokaže šta je hteo u par linija, a Eckel to isto ilustruje na par strana knjige. Ipak, 90% programera će reći da je Eckel bolji za učenje od Stroustrup-a.

Potpis

IOCC

Verovatno je ovo prica za drugi topic, tj. verujem da ima nesto vise se kaze. Prosto receno, kako da se za niz nekog tipa (char u C-u, recimo) alocira kontinualni deo memorije. Znaci pocinje od te i te adrese, i zavrsava se na toj i toj adresi, nisu bitni kraj i pocetak (adrese), bitno je da nije "razbacan" po memoriji.

Potpis

fire, walk with me

E, procitah ovde bas svasta...
Dragi Tata, bojim se da ne ostanes trajno dezinformisan u vezi Delphi-ja, pa cu zato da napisem malo precizniji odgovor. Mislim da sam za to kvalifikovan, jer radim u Delphi-ju, CBuilder-u, a radio sam i u Borland C++-u i Visual C++-u.

Dakle, Delphi nema GC za objekte definitivno. Postoji referecce counting za interface-e i nista vise. Ako to neko smatra za GC, pa i ne gresi puno.
Dalje, Delphi i C++ su razliciti k'o nebo i zemlja (nikakvi plagijati, molim lepo).
DELPHI.
Delphi kreira svoje objekte ISKLJUCIVO u dinamickoj memoriji (heap), i njegovi objekti se moraju EKSPLICITNO (rucno) unistavati pozivom destructor-a. Inace, pojedes memoriju dok kazes keks. Alokacija memorije za instance je ugradjena u constructor TObject.Create i tu se ne moze nista promeniti. TObject je APSOLUTNI ancestor za sve klase u Delphi-ju (racunajuci i tvoje); bez njega NE MOZES napraviti instancu ni jedne klase.
C++.
C++ moze da kreira objekte na DATA memoriji, STACK memoriji i HEAP-u (din. memorija). U C++ ako navedem u .cpp fajlu instancu neke klase (znaci, ne pointer na instancu) automatski sam je i kreirao (na data ili stack segmentu, svejedno). U tom slucaju, radi GC tako sto ce da ubije dati objekat cim izadje iz scope-a. Dalje, ako u .cpp navedem POINTER na instancu, tu instancu moram da kreiram sa new. Za te objekte (kreirane na HEAP-u) ne radi GC (jasno, jer GC ce da pocisti samo POINTER), a sam objekat moras RUCNO da unistis sa delete.
CBuilder.
E, on je zanimljiva tvorevina. Mozes da kreiras VCL objekte (ili nasledjene od njih) samo preko POINTERA i new; zasto? Upravo zato sto ce Delphi-jev TObject constructor da alocira memoriju za tvoju instancu na HEAP-u; tu je kraj price.
Ali...(uvek neko ali)...CBuilder je i PRAVI, PUNOKRVNI C++ kompajler koji ti omogucava i da pravis C++ klase (non-VCL) koje nemaju nikakav 'zakucan' constructor. To dalje znaci da mozes da kreiras non-VCL instance (ponavljam se) 'na DATA, STACK-u ili HEAP-u', kao u svakom drugom C++ kompajleru.
Posto sam se vec raspisao, ajde da vam kazem i ovo. Znate li zasto nije i nece nikad biti preveden VCL na C++? Iz jednog sustinskog razloga: u C++-u je redosled izvrsavanja konstruktora i destruktora nasledjenih klasa ZAKUCAN; u Delphi-ju nije. To je jedan od razloga, a ima ih jos. Toliko o plagijatima...
Pozdrav

Rajko

Ako si dobro razumeo, u pitanju je bio nacin realizacije objekata kao model, a u tom pogledu Objektni Pascal _je_ isti sa C++, a niko nije ni pomenuo alokaciju memorije, ili 'zakucavanje' destruktora i konstruktora, ili nesto drugo.

Potpis

People who think they know everything tend to irritate those of us who do.