"- Ha tobb objektumot gyujt be egyszerre a gc, amelyek hivatkoznak egymasra, akkor nem elhetsz azzal a feltetelezessel, hogy az objektum referenciai korrektek. Eleg problemassa valik a destruktorok jo implementacioja."
Ez nem tudom, hogy melyik platformra vonatkozik, mindenesetre érdemes lenne ennek jobban is utána menni, legalábbis én se arra nem fogadnék, hogy pl. javaban ez így van, se arra, hogy nem. Ott speciel a finalizerrel rendelkező objektumok (nem destruktor!) a gc futásakor bekerülnek egy sorba, ahonnan egy alacsony prioritású thread fogyasztja az objektumokat és futtatja a finalizereket. Tehát csak annyit kell csinálni, hogy amíg egy objektum ebben a sorban van, addig az általa hivatkozott objektumgráfot sem szabad takarítani, ami nem egy nehéz feladat.
"Ezert is van, hogy a C++ jobb teljesitmenykritikus programok irasara, mint a GC kornyezetek. A GC altal okozott teljesitmenyminuszt szoktak altalaban szidni, de szerintem amirol most irtam sokkal kritikusabb tud lenni, mert a programod helyesseget is befolyasolja."
Hát, én inkább azt mondanám, hogy egyrészt gc tuning és use case kérdése. Pl. ha stop the world gc-t használsz és rengeteg pici rövid életű objektumot hozol létre, a gc ritkán fog futni, de akkor, amíg le nem fut, megáll az alkalmazásod, c++ esetén meg folyamatosan érezni fogod a destruktorokból származó teljesítmény csökkenést. Viszont ha átváltasz egy másik ütemezőre ami nem STW, azzal jobb eredményt is elérhetsz, cserébe több memóriára, több cpu magra lehet szükséged.