[es] - Čišćenje objekata?

-zombie-
Tomica Jovanovic
freelance programmer
ni.ac.yu

Član broj: 4128
Poruke: 3448
*.rcub.bg.ac.yu

Sajt: localhost

+5 Profil

Re: Čišćenje objekata?

^{02.02.2003. u 23:53 - pre 258 meseci}

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:

Code:

var
l: tLabel;
begin
l:=tLabel.Create(self);
end;

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..

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

Odgovor na temu

Dragi Tata
Malo ispod Kanade

Član broj: 1958
Poruke: 3906
..ndg-pm4-1.dialup.nethere.net

+6 Profil

Re: Čišćenje objekata?

^{03.02.2003. u 02:34 - pre 258 meseci}

Citat:

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

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?

IOCC

Odgovor na temu

Riste Pejov
Team Leader/Senior Software Developer @
Ein-Sof ltd Skopje
Skopje, Macedonia

Član broj: 128
Poruke: 571
62.162.102.*

Jabber: richie@bagra.net.mk
ICQ: 154236769
Sajt: riste.softver.org.mk

Profil

Re: Čišćenje objekata?

^{03.02.2003. u 08:50 - pre 258 meseci}

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)

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

Odgovor na temu

jc denton

Član broj: 2358
Poruke: 1705
*.ptt.yu

Profil

Re: Čišćenje objekata?

^{03.02.2003. u 09:51 - pre 258 meseci}

Citat:

Dragi Tata:
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...

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.

Citat:

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?

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?

fire, walk with me

Odgovor na temu

Dragi Tata
Malo ispod Kanade

Član broj: 1958
Poruke: 3906
199.171.112.*

+6 Profil

Re: Čišćenje objekata?

^{03.02.2003. u 16:29 - pre 258 meseci}

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).

Citat:

Dragi Tata:
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...

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.

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.

Citat:

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

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.

Citat:

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

Ne razumem pitanje.

IOCC

Odgovor na temu

-zombie-
Tomica Jovanovic
freelance programmer
ni.ac.yu

Član broj: 4128
Poruke: 3448
*.rcub.bg.ac.yu

Sajt: localhost

+5 Profil

Re: Čišćenje objekata?

^{03.02.2003. u 18:23 - pre 258 meseci}

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).

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

Odgovor na temu

Dragi Tata
Malo ispod Kanade

Član broj: 1958
Poruke: 3906
199.171.112.*

+6 Profil

Re: Čišćenje objekata?

^{03.02.2003. u 18:39 - pre 258 meseci}

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.

IOCC

Odgovor na temu

-zombie-
Tomica Jovanovic
freelance programmer
ni.ac.yu

Član broj: 4128
Poruke: 3448
*.rcub.bg.ac.yu

Sajt: localhost

+5 Profil

Re: Čišćenje objekata?

^{03.02.2003. u 19:41 - pre 258 meseci}

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...

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

Odgovor na temu

Dragi Tata
Malo ispod Kanade

Član broj: 1958
Poruke: 3906
199.171.112.*

+6 Profil

Re: Čišćenje objekata?

^{03.02.2003. u 19:58 - pre 258 meseci}

Citat:

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

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.

IOCC

Odgovor na temu

-zombie-
Tomica Jovanovic
freelance programmer
ni.ac.yu

Član broj: 4128
Poruke: 3448
*.rcub.bg.ac.yu

Sajt: localhost

+5 Profil

Re: Čišćenje objekata?

^{03.02.2003. u 20:09 - pre 258 meseci}

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

Citat:

Reference Counting is commonly used to explain one kind of garbage collection, but it doesn't seem to be used in any JVM implementations.

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?

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

Odgovor na temu

Dragi Tata
Malo ispod Kanade

Član broj: 1958
Poruke: 3906
199.171.112.*

+6 Profil

Re: Čišćenje objekata?

^{03.02.2003. u 20:30 - pre 258 meseci}

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.

IOCC

Odgovor na temu

jc denton

Član broj: 2358
Poruke: 1705
*.ptt.yu

Profil

Re: Čišćenje objekata?

^{05.02.2003. u 12:39 - pre 258 meseci}

Citat:

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

Ne razumem pitanje.

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.

fire, walk with me

Odgovor na temu

Rapaic Rajko
Bgd

Član broj: 4105
Poruke: 810
80.93.225.*

+62 Profil

Re: Čišćenje objekata?

^{05.02.2003. u 18:09 - pre 258 meseci}

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

Odgovor na temu

Re: Čišćenje objekata?

^{06.02.2003. u 09:08 - pre 258 meseci}

Citat:

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

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.

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

Odgovor na temu

Rapaic Rajko
Bgd

Član broj: 4105
Poruke: 810
80.93.225.*

+62 Profil

Re: Čišćenje objekata?

^{06.02.2003. u 11:59 - pre 258 meseci}

Ok, izvinjavam se svima.
Posto sam naknadno procitao svoj gornji odgovor, uvideo sam da sam mozda zvucao preostro; to mi stvarno nije bila namera. Jos jednom se izvinjavam; radi se o tome da kad pricam/pisem o programiranju lako se 'zanesem'.

Evo i jedne male dopune, koja treba da rascisti dilemu oko owner-a u Delphi-ju. Nije to ni GC ni kompajler magija. Radi se o osobinama klase TComponent. Obratite paznju na sledece linije:

type
TMyComponent = class(TComponent);

var
MyComponent: TMyComponent;

begin
MyComponent := TMyComponent.Create(aowner: TComponent);
end;

Obratite paznju da je aowner tipa TCOMPONENT. Zasto? Sledi odgovor.
TComponent klasa sadrzi listu/property Components[index: integer]: TComponent. Sad vec pogadjate: novo-kreirani komponent SAM SEBE UBACUJE u listu Components od OWNER-a koji je takodje TComponent. Drugim recima, svaka instanca klase izvedene od TComponent-a je item liste Components od svog Owner-a; takodje, svaka takva instanca ima i sopstvenu listu Components i u njoj instance kojima je ONA SAMA OWNER. Da li sam malo razjasnio?
To dalje znaci, da ako kreirate MyComponent sa nekim owner-om (<> nil; != NULL), ne morate da vodite racuna o toj instanci; povedite racuna o owneru, jer ce on u svom destructoru da unisti sve svoje sub-komponente, a oni ce opet svoje sub-komponente itd. itd. Dalje je prosto: apsolutni owner svih komponenata na nekoj formi je sama forma i to je to.
Ali, ako kreirate komponent sa owner-om nil, onda imate cisti memory-leak (vidi moje gornje pismo)...
Iz cisto edukativnih razloga, evo i jedna sema nasledjivanja klasa:

TObject->TPersistent->TComponent->TControl->TWinControl->...

Kao sto se vidi, sve vizuelne komponente u Delphi-ju (TControl pa navise) su descendenti TComponent-a; znaci za njih vazi gornja prica o relaciji Owner-Components; verovatno otuda i zabuna oko GC-a...
Toliko zasad i pozdrav

Rajko

Odgovor na temu