Wbudowany mechanizm optymalizacji może czasami przynieść zaskakujące wyniki. Rozważmy poniższy fragment kodu:
string var1 = "text"; string var2 = "text"; bool condition = object.ReferenceEquals(var1, var2);
Wydawałoby się, że var1 i var2 stanowią dwie osobne referencje. Po uruchomieniu kodu przekonamy się jednak, że zmienna condition będzie miała wartość true. Spowodowane jest to wykonaną optymalizacją, polegającą na tym, że .NET przechowuje zbiór użytych w programie napisów. Deklarując zmienną przechowującą napis “text” pierwszy raz, .NET zapamiętuje napis w specjalnym buforze. Następnie gdy zostanie zadeklarowana ponownie ta sama wartość(“text”), nie nastąpi ponowna alokacja pamięci, a zwykłe przypisanie wskaźnika na wcześniej zapisaną wartość w buforze. Struktura adresowania wygląda więc mniej więcej tak:
Niestety nie zawsze może nastąpić optymalizacja. Poniższy kod nie zostanie zoptymalizowany i wartość condition będzie miała wartość false:
string var1 = "text"; string var2 = "tex"; var2 += "t"; bool condition = object.ReferenceEquals(var1, var2);
Ciekawostka :).
Zagadka: Czy warunek będzie spełniony?
string var1 = “text”;
string var2 = “tex”;
var2 += “t”;
if((object)var1 == (object)var2)
{
}
Odpowiedź brzmi nie, bo operator == dla typów referencyjnych (a to wymusiliśmy rzutowaniem) sprawdza czy odwołują się do tego samego obiektu.
Miło widzieć, że moje wpisy są inspiracją dla innych 😉
Mechanizm ten zwany “interningiem” dobrze został również przedstawiony: http://broadcast.oreilly.com/2010/08/understanding-c-stringintern-m.html
@oska-at.net
Albo odwrotnie;) Moj Wpis zostal opublikowany w lutym 2010 🙂
Pozdrawiam
Piotr