Ez szerintem eros tulzas, hogy csak szintaktikus diszitgetesrol van szo.
test1: ezt hivjak a javaorszagban automatikus memoriakezelesnek? Vicces. Marmint az a vicces, hogy ezt barmilyen szempontbol jobb megoldasnak gondolod, mint az mc c-n alapulo fele refcount bangingjet.
Egyfelol rossz a pelda, mert a feladat az lenne, hogy egy megosztott eroforras *azonnal* automatikusan bezarul/felszabadul, amint az utolso hivatkozas megszunik ra. No ezt a te peldad meg nem tudja (mert expliciten hivod meg a close-t, amit el lehet felejteni). De ugye megtortenhet az a csufos eset, hogy a getInputStream() valami eltarolt referenciat ad vissza. Ellenben te a test1 fuggvenyben szorgosan bezarod ha kell, ha nem (ha te vagy az utolso referencia, akkor be kell zarni, ha nem, akkor nem...).
Csakhogy ne a pofamat jartassam, mondjuk mutatom ennek a c++-analogiajat (rc):
void test1() {
std::shared_ptr is = get_input_stream();
*is << "foobar";
}
ez a kod sok mindent tud, amit jozan esszel el lehet varni eroforras kezelestol
1. Kivetelek eseten is jol mukodik
2. Ha a get_input_stream() nem tart meg referenciat az stream-re, akkor a scope vegen a stream felszabadul es a file bezarodik.
3. Ha a get_input_stream() fenntart referenciat a stream-re, akkor a scope elhagyasakor csak csokken a refcount es semmi egyeb nem tortenik.
4. Nagyjabol nulla a szintaktikus overhead ... Gondolj bele, hogy a te kodod majd hogy kezd el kinezni, ha mondjuk 3-4 streamet kell kezelni a fuggvenyben, ez a technika rosszul skalazodik.
a test2() egy szofisztikaltabb megoldas, bar meg az is bezarja az eroforrast, akkor is ha nem kellene, mert meg el egy referencia valahol.
Es a "rendes odafigyeles" resze az ervelesed leggyengebb pontja, sajnos ez nem mukodik a gyakorlatban. Eppen maga az rc es a gc azert lett kitalalva, mert a fejlesztok nem tudtak kovetni/eszben tartani, hogy milyen hivatkozasok vannak egy komplex objektumgrafban, ezert kellett valami, ami ezt megteszi helyettuk. Annyira automatikusan, amennyire lehet.