Miben különbözik C++-ban a shared pointer működése . NET-es memória menedzseléstől?

A C++-t nem ismerem, szóval inkább a .NET-ről mesélnék.

Amikor létrejön egy objektum, a .NET ehhez hozzárendel egy számot (ezt hívjuk referenciaszámlálónak). Ez a szám azt jelenti, hogy hány programozási eszköz hivatkozik arra az objektumra. Nézzünk egy egyszerű forráskódot:

[C#]

object a = new object();

object b = a;

b = null;

a = null;

Először kiértékelődik a new object() példányosító kifejezés. Ez - mivel reference-type - a heap-en létrejön, és a .NET beállítja a a referenciaszámláló értékét 0-ra.

Ezt követően kiértékelődik az object a = [az előbb kiértékelt kifejezés object típusú eredménye] értékadó kifejezés. Ennek hatására a .NET az objektum referenciaszámlálóját 1-re módosítja.

Majd kiértékelődik az object b = a kifejezés. Mivel egy újabb hivatkozás van a korábban létrehozott objektumra, szintén megnöveli a referenciaszámlálót, aminek az értéke 2 lesz.

Most a b = null értékadás értékelődik ki. Mivel eggyel kevesebb eszköz hivatkozik az objektumunkra, a .NET a referenciaszámlálót csökkenti 2-ről 1-re.

Ezt követően az a = 0 jön. Az előzőhöz hasonlóan csökken a referenciaszámláló értéke eggyel, azaz az új értéke 0 lesz. Ezzel elveszítettük minden "kapcsolatunkat" a létrehozott objektummal, amit már soha nem fogunk tudni visszakapni. És itt jön a képbe a GC (garbage collector).

A GC időnként (pontosabban "amikor neki jól esik" - akarom mondani, nem tudjuk megmondani, mikor fog aktivizálódni) végignézi a program futása során létrejött objektumokat és megkeresi azokat, amelyeknek a referenciaszámlálója nullán áll és törli őket (persze ha van destruktora az objektumnak, előbb azt végrehajtja).

Bár lehetőségünk van a .NET-től "kérni" a GC futtatását a GC.Collect() meghívásával, de ennek hatására sem lehetünk abban biztosak, hogy a GC-nek "mikor lesz kedve" lefutni.