BGAFC Vendégkönyv

Σ: 16 post

saxus (statz)

#9, Agyfasz (419)

668 | #1c20 | ^ | Idézet | Tue, 24 Apr 2012 23:15:23 +02

84.3.*.*

*.catv.pool.telekom.hu

kemi írta/wrote:
A C++, meg az Object Pascal is hagy ha óópézel, de neked kell eltakarítani. :P

Breaking news: a C meg a Pascal is hagy, ha nem figyelsz. ;)

Teljesség kedvéért tegyük hozzá, hogy a Java meg a C# GC-jét legalább felkészítették olyanokra, hogy zárt hurkokat felismerjen, ellentétben pl. a PHP-vel vagy más egyéb refcount alapján működő megoldásokat (pl. butább C++ referencia helperek).

Pl.

Class Lof
{
public Lof cucc;
}

Lof a = new Lof();
Lof b = new Lof();

a.cucc = b;
b.cucc = a;

a = null;
b = null;

Ezt a .NET és a Java észleli, ami refcounter alapján működik, az megszopta. És ehhez nem kell OOP.

saxus (statz)

#9, Agyfasz (419)

716 | #1c21 | ^ | Idézet | Tue, 24 Apr 2012 23:21:43 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
Megoldás: nem kell oop-zni.

:)) C (és egyéb nem OO nyelvben írt) kódokban nem ritkán látok objektum orientált szemléletű megvalósításokat, csak épp mivel magában a nyelvben önmagában nincs támogatás hozzá, így sokkal nyakatekertebb és kevésbé biztosabb megoldás.

Egyszer néztem pl. hogy hogyan lehetne az SDL_image -hez betolni adatot memoriából. Nos, a diagnózis az volt, hogy szenvedjen vele az, akinek hat anyja van. Gyönyörű "szépen" újraimplementáltak egy komplett stream interface-t, csak épp sokkal nyakatekertebben, mint ahogy azt általában megoldják egy átlag prognyelv library-jában, szebben, egyszerűbben, tisztább-szárazabb érzéssel.

Flood3r (statz)

#8, Lófasz (838)

690 | #1c22 | ^ | Idézet | Tue, 24 Apr 2012 23:53:23 +02

94.21.*.*

*.pool.digikabel.hu

Prometheus írta/wrote:
Egy számnak keresem a címét, amit a Radio Skipper nevű online rádióban hallottam. Sikerült fölvennem a zene egy részletét, de hiába írtam be dalszöveg-részleteket a Google-ba, nem adta ki a számot, amit én keresek. Hogy oldjam meg, hogy fölteszem egy kis internetes helyre a zenét úgy, hogy egy linkkel azonnal el lehessen érni? Szeretném Facebookon belinkelni, és bárki megmondja a címét, vendégem egy jó sörre.

Van egy oldal: http://www.midomi.com (Majdnem Midori...HaHahAhaHa) Ezen ha csak rá dúdolod vagy hümmögöd a zenét a májkrofonodba, akkor az ódal megleli. Elég sok mindent megtalál, sztem próbáld ki.

kemi (statz)

#2, Főfasz (2970)

187 | #1c23 | ^ | Idézet | Wed, 25 Apr 2012 08:42:42 +02

188.143.*.*

*.pool.digikabel.hu

A gúgli eddig is tele volt reklámmal, hiszen abból kapják a pénzt, de legalább eddig nem idegesítő módon tolták. Most a tecsőn már az ajánlott videók között jelenik meg sárgával kiemelve!

TCH (statz)

#1, Főfasz (10443)

866 | #1c24 | ^ | Idézet | Wed, 25 Apr 2012 13:40:02 +02

89.134.*.*

*.catv.broadband.hu

saxus írta/wrote:
Breaking news: a C meg a Pascal is hagy, ha nem figyelsz. ;)

Akármelyik nyelv hagyhat, a hangsúly nem ezen van, hanem azon, hogy a ciszta meg a dzsuva szükségszerűen szemetet csinál.

saxus írta/wrote:
:)) C (és egyéb nem OO nyelvben írt) kódokban nem ritkán látok objektum orientált szemléletű megvalósításokat, csak épp mivel magában a nyelvben önmagában nincs támogatás hozzá, így sokkal nyakatekertebb és kevésbé biztosabb megoldás.

A C nem tehet róla, hogy idióták is használják.

Flood3r: Én sátáni hörgések közepette elüvöltöttem neki, hogy bocibocikecske, baszikamenyecske, erre kiadta az Üzbég himnuszt. :]

kemi: Naja, de azt még el lehet viselni, ha csak ott van a listában, az a pofátlanság, ha ki is nyitja, mert erre is volt már precedens.

Flood3r (statz)

#8, Lófasz (838)

273 | #1c25 | ^ | Idézet | Thu, 26 Apr 2012 00:10:12 +02

94.21.*.*

*.pool.digikabel.hu

TCH írta/wrote:
Flood3r: Én sátáni hörgések közepette elüvöltöttem neki, hogy "bocibocikecske, baszikamenyecske", erre kiadta az Üzbég himnuszt. :]

Hát na, az Üzbégek így tolják :D Nem mindenkinek egyforma a himnusza :))

saxus (statz)

#9, Agyfasz (419)

774 | #1c26 | ^ | Idézet | Thu, 26 Apr 2012 02:34:20 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
Akármelyik nyelv hagyhat, a hangsúly nem ezen van, hanem azon, hogy a ciszta meg a dzsuva szükségszerűen szemetet csinál.

Ez hülyeség. Szemetet csak a programozó hagy "szükségszerűen". De azt minden nyelvben. A GC csak a szemét eltakarításában segít.

TCH írta/wrote:
A C nem tehet róla, hogy idióták is használják.

Most arra gondolsz, hogy OO szemléletben írnak kódot benne? :) Ezek szerint a BSD fejlesztők, (btw. nem lepődnék meg, ha Linuxban is hasonlóan menne a driverek kezelése, mivel nagyon máshogy nem lehet), az id Software dolgozói és más hasonló méretű projekteken dolgozók is idióták ;) Az OOP nyelveket is csak az arra vonatkozó igény hozta életre.

kemi (statz)

#2, Főfasz (2970)

595 | #1c27 | ^ | Idézet | Thu, 26 Apr 2012 08:49:35 +02

193.224.*.*

*.uni-obuda.hu

TCH írta/wrote:
kemi: Naja, de azt még el lehet viselni, ha csak ott van a listában, az a pofátlanság, ha ki is nyitja, mert erre is volt már precedens.

Az is van, ráadásul benne a flashben, hogy ne tudd kikerülni.

saxus írta/wrote:
Ez hülyeség. Szemetet csak a programozó hagy "szükségszerűen". De azt minden nyelvben. A GC csak a szemét eltakarításában segít.

Ha nem idióták gányolnának programozás gyanánt, és nem olyan nyelvet használnának ami szükségszerűen szemetet generál, GC-re se lenne szükség.

TCH (statz)

#1, Főfasz (10443)

2245 | #1c28 | ^ | Idézet | Thu, 26 Apr 2012 13:58:19 +02

89.134.*.*

*.catv.broadband.hu

Flood3r írta/wrote:
Hát na, az Üzbégek így tolják :D Nem mindenkinek egyforma a himnusza :))

Izé, trollsmiley megvolt a végén? :) Csak poénkodtam, nincs is mikrofosom mikrofonom. :P

saxus írta/wrote:
Szemetet csak a programozó hagy "szükségszerűen".

Tény, hogy a hülye programozó szemetel, de a szar nyelv is. Akárhogy is programozol dzsuvában vagy cisztában, szemetelni fog.

saxus írta/wrote:
Most arra gondolsz, hogy OO szemléletben írnak kódot benne? :)

Nem én az OOP túlerőltetett és felesleges alkalmazására gondoltam, de neked megint trollkodhatnékod van és kiforgatod a szavaimat. Rosszat tesz neked a HUP. :P

saxus írta/wrote:
Ezek szerint a BSD fejlesztők, (btw. nem lepődnék meg, ha Linuxban is hasonlóan menne a driverek kezelése, mivel nagyon máshogy nem lehet), az id Software dolgozói és más hasonló méretű projekteken dolgozók is idióták ;)

Nem tudom, hogy melyik kernel fejlesztő vagy játékgyáros mit miért csinál, de mint az előző bekezdésben tisztáztuk, a túlerőltetett OOP az ami idiotizmus, nem az OOP maga. Azért rühellem, mert mindenre azt alkalmazzák. És CPU szinten nincsenek ojjektumok, szóval igazából bármit le lehetne fejleszteni OOP nélkül is, úgyhogy ez az állítás, hogy driverszinten máshogy nem is lehet, mint OOP módban, ez közönséges bullshit.
Az bloated és bugos Linux kernelt meg hagyjuk.

saxus írta/wrote:
Az OOP nyelveket is csak az arra vonatkozó igény hozta életre.

Igen, az, hogy mozgatható kód/adatblokkokat - objektumokat - lehessen létrehozni, de manapság mindenre szükségszerűen ezt alkalmazzák, hulla feleslegesen.

kemi írta/wrote:
Az is van, ráadásul benne a flashben, hogy ne tudd kikerülni.

A flashben? Hát nem tom, de nekem itt melóhelyen nincs flash és van reklám a HTML 5-ös videókban, odahaza meg van flash és nincs reklám. Nem a HTML 5-ös cumókba nyomják bele véletlen?

kemi írta/wrote:
Ha nem idióták gányolnának programozás gyanánt, és nem olyan nyelvet használnának ami szükségszerűen szemetet generál, GC-re se lenne szükség.

Jaja.

kemi (statz)

#2, Főfasz (2970)

108 | #1c29 | ^ | Idézet | Thu, 26 Apr 2012 22:28:03 +02

188.143.*.*

TCH írta/wrote:
nincs is mikrofosom

Az csak sztívballmernek van. :)

TCH (statz)

#1, Főfasz (10443)

515 | #1c2a | ^ | Idézet | Thu, 26 Apr 2012 23:40:29 +02

46.107.*.*

*.catv.pool.telekom.hu

kemi írta/wrote:
Az csak sztívballmernek van. :)

saxus, melyik terheli le jobban a szervert, a require vagy a memcached::get?
Csak mert, most kipróbáltam, hogy fogok egy tömböt, beteszem memcachedbe, meg kiteszem egy külső php fájlba ($xyz = array(...)) és kibenchmarkoltam, hogy melyik gyorsabb, oszt a memcached sokkal lassabb volt, amit kurwára nem értek. Vagy csak az van, hogy egyszer berántotta a php a fájlt, bezúzta bytecodeként a filecachebe és az volt gyors?

saxus (statz)

#9, Agyfasz (419)

1663 | #1c2b | ^ | Idézet | Fri, 27 Apr 2012 15:48:05 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
Akárhogy is programozol dzsuvában vagy cisztában, szemetelni fog.

Mit, mégis mit fog szemetelni, áruld már el? Konkrétumokat, ne olyat, hogy "több memóriát eszik, mint az xyz".

TCH írta/wrote:
Nem én az OOP túlerőltetett és felesleges alkalmazására gondoltam

Hol lenne túlerőltetve?

TCH írta/wrote:
szóval igazából bármit le lehetne fejleszteni OOP nélkül is

Nem az a kérdés, hogy lehet-e, hanem, hogy mivel hatékonyabb. GUI írására pl. az OOP és az eseményvezérelt programozás sokkal-sokkal hatékonyabb, nem véletlen, hogy gyakorlatilag az összes GUI toolkit OO szemléletű, még a C-ben írt GTK is. (Más kérdés, hogy mivel C-ben nincsenek objektumok, GTK-ban hányadék kódot lehet írni.)

TCH írta/wrote:
A flashben? Hát nem tom, de nekem itt melóhelyen nincs flash és van reklám a HTML 5-ös videókban, odahaza meg van flash és nincs reklám. Nem a HTML 5-ös cumókba nyomják bele véletlen?

HTML5 is the new cancer. Flashplugin egy instabil szar tud lenni, bár ott is általában az böngésző illesztéseket tudják jól elcseszni (abban sem vagyok meggyőződve, hogy csak a flashben), valamint azzal, hogy a tisztelt dájzinger se ismerte a flasht normálisan és hülyeségeket csinál, attól lesz erőforrás-igényes. De a tapasztalatom az, hogy egy jól megírt flash cucc még mindig sokkal-sokkal gyorsabb, mint egy HTML5-ös csuda. Jó példa erre a Command & Conquer Tiberium Alliances. "Modern" HTML-es webapp az egész. Akad a hang 2012-ben, basszákmeg. MIEZAHULLADÉK?

TCH (statz)

#1, Főfasz (10443)

3285 | #1c2c | ^ | Idézet | Fri, 27 Apr 2012 17:21:50 +02

46.107.*.*

*.catv.pool.telekom.hu

A memchached kérdésemet megint kihagytad bazzeg, mint a múltkor az órákült. :P

saxus írta/wrote:
Konkrétumokat, ne olyat, hogy "több memóriát eszik, mint az xyz".

Az, hogy több memóriát eszik az egy dolog, de leakel mint a picsa, otthagyja a szarjait és nem szabadítja fel, GC rox; pl. létrehoz mondjuk egy threadet, az betölt egy osztályt, az osztály allokál egy nagyobb porció memóriát, aztán a referenciát tárolja a szálban, a szál meg törli a referenciát, a GC meg mehet kecskét baszni. (Netről lopott példa, neménvótam, én nemtunnijáva.) Tudom, ez egy példa arra, hogy mit nem szabad csinálni, csakhogy C#-t és Java-t baromi sokan használják, (tudtommal a Java a második legnépszerűbb nyelv a világon a C után) és elsősorban nem a computer expertek használják, hanem vizuálbuzikról átnyergelt balfaszok és a balfaszok elkövetnek ilyesmit. Nem is kell, hogy ennyire konvulens legyen, elég, ha faszul szabadítasz valamit és lábon lövöd vele a GC-t.
És mivel te megszabtad nekem, hogy ne azt írjam, hogy több memóriát eszik, mint xyz, ezért te se írd vissza, hogy a faszul megírt felszabadítás C-ben is memleakhoz vezet.
Námbör kettő példa a szükségszerű szemetelésre, hogy mindent túlbonyolítva tárol le, nem értem, hogy egy kurwa integernél miért kell lehetővé tenni, hogy példányosítani lehessen. (Demajdtemingyámegmondod.)

saxus írta/wrote:
Hol lenne túlerőltetve?

Most soroljam fel? Ezer helyen. Én legtöbbször PHP-ban futok vele össze, mivel webgányerként tengetem szaros életem, mégszarabb napjait: rakatszor látok rakat alsógyatya rendszereket, ahol olyan szinten van minden kiszervezve osztályokba, hogy az ember az asztallappal vakarja az arcát; a legegyszerűbb feladatra is osztályba szervez mindent a sok balfasz és akkor a kiterjesztés kiterjesztésének a kiterjesztését kiterjesztjük, azért, hogy kirakjunk három kibaszott input fieldet a kibaszott képernyőre. Aztán csodálkoznak, hogy a formkezelő osztály és az extensionok többszáz kilót nyomnak és hogy lasssssssssúúúúúú, mint egy reumás csiga...

saxus írta/wrote:
GUI írására pl. az OOP és az eseményvezérelt programozás sokkal-sokkal hatékonyabb

Ezt már Csárli is mondta, de el nem magyarázta, meg példát sem mondott. Just take my word for it.
De tegyük fel, hogy ez így van és GUI-ra az OOP való, de egy kernelbe (te említetted), minek OOP?
Az meg, hogy miben lehet hatékonyabban megírni... It's the programmer, not the language.

saxus írta/wrote:
HTML5 is the new cancer.

Biztos, én nem másztam bele ennyire, csak olyan dolgokat használok belőle, mint a slider, vagy a number field, meg ilyenek. De egyébként nálam tutira így van, hogy melóhelyen nincs flashplugin és van reklám a tecsővideóban, idehaza meg van flashplugin és nincs reklám a tecsővideóban. Persze lehet, hogy csak a 300 soros blacklistem miatt nincs reklám, mert a szerver ahonnan jönne, kiblokkolódik, de ez csak tipp. :P

http://hup.hu/cikkek/20120427/20_dollarert_tortek_hotmail_account-okat
Olyan sebezhetőség, hogy egy percen belül törhető, fasza rendszer lehet az a hotmél...

http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/

saxus (statz)

#9, Agyfasz (419)

4298 | #1c2d | ^ | Idézet | Sat, 28 Apr 2012 01:17:32 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
pl. létrehoz mondjuk egy threadet, az betölt egy osztályt, az osztály allokál egy nagyobb porció memóriát, aztán a referenciát tárolja a szálban, a szál meg törli a referenciát, a GC meg mehet kecskét baszni.

TCH írta/wrote:
hogy a faszul megírt felszabadítás C-ben is memleakhoz vezet.

Nem egy faszul megírt felszabadítás konkrétan összeomláshoz vezet ;)

TCH írta/wrote:
a legegyszerűbb feladatra is osztályba szervez mindent a sok balfasz és akkor a kiterjesztés kiterjesztésének a kiterjesztését kiterjesztjük, azért, hogy kirakjunk három kibaszott input fieldet a kibaszott képernyőre

Ez kb. pont azért szar példa, mert a keretrendszerünkben nem véletlen tértünk át a "switch-way" megoldásról egy OOP szemléletűbb megoldásra: egyrészt rugalmasan lehetett bővíteni a mezőtípusokat, generátorokat, másrészt a kimeneti formátum is transzparensen bővíthető lett (HTML, szerkeszthető, CSV, Excel, PDF, stb.) Validálás meg nem úgy nézett ki, hogy az adott modulba írtam csilliónyi validálási függvényt, hanem az előre megírt validátorokat dobáltam hozzá. Lassabb volt, mint a hardcoded régi út? Igen. Elbírta a gép? Igen. Töredék idő alatt megoldottunk nagyobb funkcionalitást? Igen.

Persze, egyszerű oldalra nem ezt fogom használni.

TCH írta/wrote:
de egy kernelbe (te említetted), minek OOP?

Érdemes elolvasni az MS Research féle Singularity-ról szóló papereket. Egyébként lenne sok helyen értelme, pl. mindenhol ahol egy interface-t kell definiálnod: nem csillió függvénypointert adsz át, hanem egy osztályt. Vagy bárhol, ahol cserélgethetőnek kell lennie valaminek. Pl. schedulerek.

Ezen kívül egy normálisan megírt osztály egyszerűbben egységtesztelhető (lenne, ha pl. ilyenre adnának a Linuxnál ;), és nincs minden globális változóként belehányva a nagyvilágba.

De mondok egy másik példát: most fejlesztek az ügyviteli rendszerünk mellé néhány kiegészítő dolgot. Áll egy szerver és egy kliens részből. Egy fontos tulajdonsága, hogy van egy szabályrendszer benne (amolyan nagyon leegyszerűsített scriptnyelv féleség, csak nem megírt kóddal, hanem összekattintgatós felülettel, ciklusok és hasonlók nélkül. Lényegében csak képlet, változók, és IF-THEN,IF-THEN-ELSE ami van benne, szándékosan egyszerűsítve). A képletekben vannak függvények. Egyes függvényeknek más a működése szerver és kliens oldalon. Pl. szerver oldalon csak simán lekérded az ügyviteli rendszerből az árfolyamot. Kliens oldalon meg ehhez el kell nyúlni a szerver oldalra.

Persze, lehetett volna switch-case-al is kiválasztani, csak épp az úgy egy hányás, ráadásul bizonyos dolgok (pl. az ügyviteli rendszer DB-je) szimplán elérhetetlen a kliensből. Itt van az, hogy a GetArfolyamFunction() vár egy IArfolyamProvider interface-t, amelynek van egy GetArfolyam(string) metódusa, amely visszaadja nekem az árfolyamot. Amikor létrehozom a függvényt, akkor ugye a megfelelő árfolyamlekérő megoldást adom át neki.

Persze, lehetne ezt függvénypointerekkel is megoldani (elméletben), gyakorlatban meg elég undorító katyvasz lenne a vége. Ugyanis kliensoldalon az ottani ArfolyamProvidernek kell egy IClientHandler, amely segítségével tudok üzenetet küldeni a szervernek (valójában a NetworkModule -t kapja meg), szerver oldalon meg attól függően, hogy a konfig állományba mit adok meg, kaphat FakeArfolyamProvider-t (szimpla fejlesztéshez használt konstans érték) vagy másikat (amelyik ténylegesen kiolvassa az adatbázisból - nyilván ehhez át kell adni a megfelelő db-t. Megjegyzem, többhöz is kapcsolódik a szerver -) vagy akár egy teljesen másik megoldást. (Pl. élő árfolyam lekérdezés netről).

Tipikusan ezek az esetek, amikor jó az OOP, még ha elsőre több is a kód, mint sima struktúrált kódnál. Nem azért, mert gyorsabb lesz, hanem mert rugalmasabb.

TCH írta/wrote:
http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/

Na a funkcprog után ne szóljál be az OOP-re ;) Ha valaminek _tényleg_ nincs köze a CPU belső lelkivilágához, az a funkcionális programozás, ahol már tényleg inkább azt írod, hogy mit akarsz végeredménynek, mintsem, hogy mit csináljon a CPU.

saxus (statz)

#9, Agyfasz (419)

1057 | #1c2e | ^ | Idézet | Sat, 28 Apr 2012 01:25:30 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
saxus, melyik terheli le jobban a szervert, a require vagy a memcached::get?
Csak mert, most kipróbáltam, hogy fogok egy tömböt, beteszem memcachedbe, meg kiteszem egy külső php fájlba ($xyz = array(...)) és kibenchmarkoltam, hogy melyik gyorsabb, oszt a memcached sokkal lassabb volt, amit kurwára nem értek. Vagy csak az van, hogy egyszer berántotta a php a fájlt, bezúzta bytecodeként a filecachebe és az volt gyors?

Lássuk memcached-et:

- TCP connection felépítése
- TCP kérés küldése
- TCP válasz feldolgozása
- Adat előkerítése a memcachedből
- Adat kiküldése TCP-n
- Adat fogadása
- Adat átalakítása PHP-s stringre
- Tömb deserializálása
- örömboldogság

File:
- Fájl előkotrása (valószínűleg memóriából) - valószínűleg ki van optimalizálva
- Fájl beolvasása
- PHP értelmező fut a tömbre
- örömboldogság

Sosem benchmarkoltam, de szerintem a serializáció nem annyira gyors művelet és nincs annyira kioptimalizálva, mint a PHP értelmező. Mondjuk sebességeket nem írtál, hogy mi mennyi volt.

saxus (statz)

#9, Agyfasz (419)

3224 | #1c2f | ^ | Idézet | Sat, 28 Apr 2012 01:50:07 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:

pl. létrehoz mondjuk egy threadet, az betölt egy osztályt, az osztály allokál egy nagyobb porció memóriát, aztán a referenciát tárolja a szálban, a szál meg törli a referenciát, a GC meg mehet kecskét baszni.

Na, amit akartam írni, csak elfelejtettem. Na ez az, amit nem csinál meg egy menedzselt nyelv. Eleve a threadoknak semmi köze a memória allokációnak. Amit stacken foglalsz az a stack felszabadításával eleve törlődik (annak kezelésében AFAIK eleve nincs is különbség pl. egy C-hez képest). Sőt, maga a szál nem tárol semmilyen referenciát (mégis hol tárolna? Max., ami stacken tárolt referencia, de a referenciák pont ezért többek egy sima pointertől.)

Ami meg a heapon foglalódik, az meg eleve nem refcounter alapján megy (különben tényleg el lehetne leakelni, mint pl. a PHP-t, vagy egy refcounteres memory managert). Jó, gondolom van az is, mert az a leggyorsabb módja annak, hogy megállapítsuk, hogy van-e élő referencia az objektumra. De már írtam, hogy mind a Java, mind a C# képes detektálni az elérhetetlen referenciákat és fel fogja szabadítani. Nem azonnal, de amikor van szabad CPU idő vagy szükség van rá, fel fogja. (Azt viszont meg nem mondom, hogy milyen gráfbejárásos csodával állapítja meg ezeket).

Ugyanis a memóriamenedzsment úgy működik, hogyha valami miatt egy objektum memóriaszemétnek minősül, akkor bekerül egy Finalization Queue-be, amelyet a GC a következő futásakor kihajít a francba. (Pontosabban itt még kerülhet egy Freachable queue-be, ha pl. van finalizer - (kb. destruktor helyi megfelelője))

Amivel viszont valóban el lehet leakelni, az az, ha valamilyen olyan resource-t használsz, amely kívül esik a menedzselt hatókörön és/vagy OS erőforrásokat foglal le. Pl. file descriptor, valamilyen resource, pl. Font (ugye a Windows fontkezelését használja a háttérben), vagy COM interop. Valamint ide tartozik az is, amit pl. unmanaged környezetben hozol létre (ha pl. C++/CLI-ben foglalsz le malloc-al vagy new -el* vagy a Marshaling-on keresztül matatsz valamit.)

De pl. pont ezekre van .NET-ben az using() {} nyelvi elem, amely ezeknek megakadályozására szolgál. Amennyiben kilépsz az adott context-ből, meghívja a Dispose() metódust az adott objektumon. (.NET -ben az IDisposable pattern van arra, hogy az ilyen erőforrásokat, amelyeket muszáj kézzel felszabadítani, meg tudd tenni.)

Vagy a try-catch -nak is azért van finally szakasza, mert az mindig lefut, akár volt exception, akár nem, pont azért, hogy a takarításokat valahol meg tudd oldani.

(Na persze, a .NET -es GC-nek is vannak meredek trükkjei, pl. lehetséges megölhetetlen objektumot létrehozni azzal, hogy a finalizerben valami kívülről elérhető referenciát rakunk meg újraregisztráljuk a GC-nél finalizálásra az objektumot. Persze ez ilyen nagyon ocsmány dirty trükk, inkább nyelvi érdekesség, mintsem valós felhasználás. Egyébként se szokás a finalizert nagyon használni, egyrészt mert ki tudja mikor fut a GC, másrészt gyakorlatban nemigazán van rá szükség, harmadrészt a felszabadításokat jellemzően a Disposable pattern keretein belül szokás megoldani.)

* C++/CLI -ben gcnew/gcdelete van a managed dolgokra, a new/delete maradt a natív C++ dolgokra