pa u sustini trebalo bi da je tako ,

dinamicki alocirani delovi memorije su na heap-u , na linuxu je to oko 0x0804xxxx adresa


tako da bi to trebalo da radi

Rekoh, ovo resenje ne radi korektno sa statickim promenljivama.


Ovaj program ispisuje poruku "Promenljiva je dinamicka", sto je netacan rezultat.

e svasta , nisam ni video taj deo

naravno da ce biti tako , nisam se setio toga

pa , mozes da pogledas gde ti se krecu segmenti , u kojim adresama

posto ce dinamicke biti iskljucivo na heap-u , ostale u .bss , .data i sl , svaki od segmenata
ima odredjen raspon adresa koji zauzima,

e sad , dok nije bilo randomizaciju u kernelu sto se tice steka , biblioteka i sl

to si mogao da hardcodujes , tj adrese su bile stalne ,

sad bi verovatno morao da ih utvrdis po pokretanju programa ,

sto sumnjam da bi bilo tesko

da li se to pitanje odnosi iskljucivo za linux ili bi trebalo da radi univerzalno ?

pozdrav ,
Aca





_{[Ovu poruku je menjao EArthquake dana 05.06.2008. u 18:59 GMT+1]}

Ukratko, ne može - bar ne na portabilan način.

bas me bacilo u razmisljanje , ali izgleda da osim da , recimo , citas /proc/PID/maps pa da uporedjujes adrese segmenata
ne vidim drugo resenje

a to definitivno nije portabilno

na windowsu nemam pojma kako bi moglo

Pa, treba da radi minimum na Linux i Windows platformama. Da li mogu da pretpostavim da su staticke promenljive na adresama ispod heap-a, a lokalne iznad heap-a?

A za šta se ovo koristi?

Pravo pitanje je "Cemu ovo sluzi?". E onda neko moze da kaze "A uz to i ne radi". Ova ideja koju Nedeljko koristi je nekada davno i mogla da prodje, ali danas zaboravite na to.

Imam klasu koja treba u sebi da sadrži pokazivač na istream tako da iz nje čitam znakove, ali ne baš onako kako idu iz ulaznog toka, nego malo obrađene. Rado bih predao klasi pokazivač na tok i prepustio joj odgovornost za uništavanje objekta (da ja ne razmišljam o delete), ali šta ako joj poturim referencu na cin (standardni ulaz) ili neki drugi tok koji nije na heap-u? Destruktor klase mora da "zna" da ne sme da ga. No, rešio sam problem na drugi način.

Klasa ima bool polje destroyInput koje namešta konstruktor. Podrazumevani konstruktor namešta input na &cin i destroyInput na false. Konstruktor koji prihvata string fileName radi input = new ifstream(fileName.c_str()); destroyInput = true; a konstruktor koji prihvata referenci na istream usmerava input na njegovu adresu i stavlja destroyInput na false. Konstruktor kopije je privatan.

Hmm, to mi deluje kao veoma los koncept, objekti i svi ostale heap strukture treba da budu unistavani u kontekstu u kom su kreirani. Sta ako ti objekat kojem si dao stream baci exception pre nego sto uradi delete? Kontekst koji je kreirao stream smatra da je problem resen a objekat ostade na heap-u, eto memory leak-a.

Pa upravo se to i postize.

1. Ako predajem kreirani tok klasi, klasa nije odgovorna za unistavanje toka.
2. Ako tok treba da bude fajl, konstruktoru se predaje samo ime fajla, klasa kreira tok i unistava ga.
3. Ako je primenjen podrazumevani konstruktor, onda se koristi standardni ulaz cin i klasa nece pokusati da ga unistava.

Moj komentar je bio na tvoj prvobitni plan da selektivno unistavas stream koji ti je prosledjen unutar klase.

Pa, i tada sam hteo da sve što ja kreiram bude na heap-u, a ostalo ionako nije na njemu.