Kako mislish "da li curi"?
Ako si neshto alocirao sa "new", a nigde do kraja programa nemash odgovarajuci "delete", naravno da imash memory leak.
Prodji na kraju programa kroz celu listu novokreiranih nodova i pobrishi ih.

Ma pretpostavljam i ja da imam memory leak, cak sam bio prilicno siguran. Ali eto da opet provjerim...
A znam i kako cu dealocirat.
Thanx

Najlakše je da override-uješ new i delete operatore i da pamtiš svaku alokaciju.
Tako na kraju izvršavanja programa možeš lako znati u kom fajlu/redu imaš leak.

Najlakše je da koristiš ovako nešto:
http://www.codeproject.com/tools/visualleakdetector.asp

Činjenica, mada je ipak bolje napisati svoje rešenje koje će raditi i na drugim platformama.
Veoma zanimljiva ideja da se pamti call-stack za svaku alokaciju, mada već imam
nekoliko platformi u glavi koje to ne bi podnele (zbog male količine memorije) :)

Ako je ovo čitav program, onda leakova memorije nema, jer će OS uništiti cijeli adresni prostor po izlasku procesa :)

Nisam nikad koristio custom alokatore, kad me zanima potrošnja memorije programa samo dodam performance counter za Virtual Bytes i Peak Virtual Bytes, veće neslaganje između njih bi trebalo ukazati na loše baratanje memorijom..

Da li si baš siguran? Probaj program da pokreneš pod operativnim sistemima DOS. Win16, Win9x. Pod Win16 nisam isprobavao (jer ga nikad nisam ni imao na mašini). Mislim da MS DOS neće osloboditi zauzetu memoriju, a na Win 98SE se nakon izvršenja takvog procesa javlja problem kod gašenja sistema. To što si rekao zavisi od OS-a. Na Win2000, WinXP i GNU/Linux sistemima svakako nema nikakvih problema. U svakom slučaju, oslobađanje memorije od strane procesa, a ne OS-a je stvar osnovne programerske kulture. Ja sam u C++ jeziku za automatske pokaziveče.

Naravno da neće raditi za real-mode OS-eve (MS-DOS i njegova 16-bitna grafička sučelja eehh) koji uopće ne poznaju koncept virtualne memorije ;) Na svim modernim OS-evima u zadnjih 10 god ne bi trebalo biti problema. NT kernel održava AVL stablo VAD (Virtual Address Descriptor) struktura koje opisuju izgled procesovog adresnog prostora (opseg rezerviranih (svaki page mora biti rezerviran prije nego je committed, tako da sigurno ovdje završi) pages, permisije, dijeljenje..).

Na Solarisu je to također AVL-stablo seg_t struktura, i odatle dolazi famozni pojam segmentation fault, kad se dereferencira virtualna adresa neprisutna ni u jednom mapiranom segmentu. Generirani SIGSEG se sinkrono dispatcha u procesov uarea (koji služi za dispatching signala preko aslwp LWP-a) iz ISSIG makroa pri izlasku iz pozvanog syscalla ili iz recimo page fault handlera. Vjerojatno je sl. na linuxu i ostalim *nixoidima.

Što se tiče općenito memory leakova na Windows platformi, važno je zapamtiti da memory leakovi povećavaju procesovu privatnu virtualnu veličinu, a ne veličinu working seta. WS je veći od stvarne potrošnje procesa jer se za svaki proces broje i shared pages. Za točniju potrošnju od ukupne fizičke memorije treba oduzeti slobodnu memoriju (Available bytes), memoriju koju koristi OS (nonpaged pool, resident page pool, resident OS & driver code), te veličinu modified liste. Veličinu ovog zadnjeg faktora je moguće dobiti jedino iz kernel debuggera (!vm 1 komandom).

Što se tiče std::auto_ptr, to će u principu raditi samo za objekte alocirane unutar scope-a, jer će pri njihovom izlasku se automatski pozvati delete nad objektima sa kojim su kreirani. Ali to znači da objekt neće biti oslobođen ako sve do kraja bloka, čak i ako nije više potreban nakon nekog trenutka! Koliko sam shvatio, auto_ptr nije najsretnije rješenje za dijeljene objekte u multithreaded okolini, pored zaštite od double deletion i sl. suptilnih bugova, jer je pravilno implementirati prenošenje ownershipa sa jednog threada na drugi pravi PITA, pogotovo recimo za Javu koja je 10 god imala problema sa tim (mislim da je taj problem riješen u Javi 5).

Najbolje bi bilo da je C++ bio projektiran da podržava GC od samog početka. Šteta što su Stepanov, Stroustrup, Koening i ostala ekipa iz Bel labsa imali puno glupih predrasuda za GC. U zadnjih 20 god, ne postoji ni jedan jedini novi mainstream jezik koji nema integriran GC, i C++ ima sve pretpostavke da u roku 5 god potpuno preuzme tron COBOL-a 90-ih po tom pitanju, ako se nešto radikalno ne promijeni (a neće).

Je'l ti to o std::auto_ptr pričaš?

Baš si me zbunio sa automatskim pokazivačima. Kao da čitam neku od knjiga Laszla Krausa. :)

Predlažem da prelistaš "The Design and Evolution of C++" pre nego što sledeći put napišeš tako nešto ;) http://www.research.att.com/~bs/dne.html

C++ jednostavno ne može da ima "obavezan" GC zbog svoje namene (low-level sistemski jezik) i kompatiblinosti sa C-om. Inače, "pametni pointeri" kao što su oni iz Boost biblioteke koji su već na putu da uđu i u standard, su najčešće sasvim dobro rešenje za automatsko upravljanje memorijom.



Kad su u pitanju interne biznis aplikacije, C++u je već odavno odzvonilo. Međutim za sistemske, real-time, grafičke, multimedijalne itd. primene trenutno ne vidim nikakvu alternativu osim C-a i eventualno Fortrana ;)

Mešanje baba i žaba ne ide. C++ i GC ne ide. Sam jezik nije dizajniran za tako nešto. Postoji CLI ali to je već nešto drugo.



Ti si stvarno odvojen od realnosti. U svetu windowsa klasičan C++ je praktično mrtav kad se priča o novim klasičnim GUI aplikacijama. Samo se održavaju postojeće i sve se lagano portuje na .NET .

C/C++ će se koristiti za realtime aplikacije, matematiku, igre, drajvere i ostale low-level stvari.

Jedina platforma gde se jos masivno koristi C++ za biznis aplikacije i GUI klasiku je UNIX/Linux. Mada i tu se trude da idu na javu ako može.

Upravo je odsusustvo GC-a ono što ga čini podesnijim za razvoj real-time softvera (kao što su video igre, multimedija itd.) u odnosu na jezike sa GC-om. GC uvodi nedeterminizam. Nikada se ne zna kada će se uključiti, a vrlo skupa operacija je u pitanju. CAD se i dan-danas radi u jeziku C++.

Postoje jezici sa pitomijim GC-om, kao što su PROLOG i LISP. U PROLOG-u se liste realizuju preko binarnih drveta, i svaka druga vrsta grafa pokazivanja između objekata u memoriji je nemoguća, pa je lako napraviti deterministički GC. Sa druge strane, u jezicima kao što je C#, graf pokazivanja između objekata u memoriji može biti bilo kakav, pa je i GC nedeterministički.