2010. június 10., csütörtök

Megmondom mit ír ki

A tegnapi kérdés megoldása: False, True... Gondolhattátok volna? :) Hehehe. Na de miért, az a nagy kérdés, azt is megmondom.

Szóval a második összehasonlítás értéke nem azért True, mert mindkét string "true", illetve azért, csak nem úgy, hanem... ehh. Kezdjük az elejéről.

A .NET-ben a string immutable, ami annyit tesz, hogy az értéke sosem változhat meg. Egyszer értéket adsz neki, úgy marad. A különböző sztring-mogyorózó műveletek is (.Replace(), .Substring(), .Trim(), stb), bár példány-metódusok, nem az adott példány állapotát változtatják meg, hanem egy új string példányt adnak vissza.

Nézzük példaként az alábbi kódot:

object o1 = "true";
object o2 = "true";
Console.WriteLine(o1 == o2);
Itt mind az első, mind a második sorban leírt sztring-konstans értéke "true", és az is marad, megváltoztathatlanul, örökre. De akkor minek kétszer tárolni, ha úgy is ugyanaz mindkettő, és nem lehet változtatni rajta?

Nos, nem kell kétszer tárolni, sőt, ami a legjobb, ezzel a spórolással nekünk nem is kell törődni, mert a .NET CLR automatikusan megteszi helyettünk. Csak egy darab "true" értékű string példány fog létrejönni, és mind az o1, mind az o2 referencia rá fog mutatni. Így o1 egyenlő lesz o2-vel - de ehhez az egyenlőség-vizsgálathoz már nem sok köze van a "true" stringnek, az összehasonlítás azt figyeli, hogy referenciálisan egyenlőek-e ("ugyanoda mutatnak-e", mondaná az unmanaged világ).

Ebben a kódban viszont a StringBuilder .ToString()-je "bekavar", nem az intern pool példányát fogja visszaadni, hanem egy újat, így ez az o1 ami nem lesz referenciálisan egyenlő a o2-vel:

object o1 = new StringBuilder("true").ToString();
object o2 = "true";
Console.WriteLine(o1 == o2);

0 megjegyzés:

Megjegyzés küldése