Miłosz Orzeł

.net, js/ts, html/css, arduino, java... no rants or clickbaits.

Modyfikator ref dla typów referencyjnych i odrobina SOSu

Spójrz na poniższy kod i zastanów się jaka wartość zostanie wyświetlona na konsoli (pamiętaj, że string to typ referencyjny)?

using System;
               
class Program
{
    static void Test(string y)
    {
        y = "bbb";
    }

    static void Main()
    {
        string x = "aaa";
        Test(x);
        Console.WriteLine(x);
    }
}

Prawidłowa odpowiedź (aaa) nie jest wcale taka oczywista. Użytkownik zobaczy napis aaa, dlatego, że bez użycia modyfikatora ref, program napisany w C# przekazuje do metody kopię wartości parametru (dla typów wartościowych) lub kopię referencji (dla typów referencyjnych).

Gdy do parametru y w metodzie Test przypisywany jest nowy tekst, CLR nie modyfkuje tablicy znaków. Zamiast tego tworzy nowy string (więcej info tutaj) i przypisuje wskazanie do niego do zmiennej y. Zmienna y znajdująca się w metodzie Test jest jednak tylko kopią referencji do napisu wskazywanego przez zmienną x z metody Main. Skoro zmodyfikowana została jedynie kopia, to po wyjściu z metody, na konsole trafia pierwotny napis aaa.

By rzeczywiście zmienić tekst kryjący się pod zmienną x, użyj modyfikatora ref (musisz dodać go zarówno w deklaracji metody jak i jej wywołaniu – C# wymusza takie zachowanie by zwiększyć czytelność kodu):

using System;
               
class Program
{
    static void Test(ref string y)
    {
        y = "bbb";
    }

    static void Main()
    {
        string x = "aaa";
        Test(ref x);
        Console.WriteLine(x);
    }
}

Po takiej zmianie na konsole trafi napis bbb.

 

SOS

Sposób przekazywania parametrów do metody można zbadać za pomocą narzędzia SOS (Son of Strike). Posłużymy się poleceniem CLRStack -a, które wyświetli informacje o parametrach i zmiennych lokalnych na stosie kodu zarządzanego (jeśli nie wiesz jak używać SOS patrz tutaj i tutaj, jeśli dziwisz się skąd nazwa "Son of Strike" kliknij tu)...

Poniżej znajdują się rezultaty polecania CLRStack -a, wykonanego w momencie wejścia do metody Test.

Dla kodu bez modyfikatora ref:

!CLRStack -a
OS Thread Id: 0x176c (5996)
Child SP IP       Call Site
0031f114 00390104 Program.Test(System.String)
    PARAMETERS:
        y (0x0031f114) = 0x025cb948

0031f158 003900af Program.Main()
    LOCALS:
        0x0031f158 = 0x025cb948

0031f3c0 656721bb [GCFrame: 0031f3c0]

Dla kodu z modyfikatorem ref:

!CLRStack -a
OS Thread Id: 0x934 (2356)
Child SP IP       Call Site
001dee34 002f00f4 Program.Test(System.String ByRef)
    PARAMETERS:
        y (0x001dee34) = 0x001dee78

001dee78 002f00aa Program.Main()
    LOCALS:
        0x001dee78 = 0x027fb948

001df0ec 656721bb [GCFrame: 001df0ec]

Istotną różnicą widoczną na powyższych zrzutach jest wartość parametru y. W przypadku kodu bez modyfikatora ref jest to adres stringa aaa (0x025cb948), natomiast dla kodu z modyfikatorem ref, wartością parametru y jest adres zmiennej x z metody Main (0x001dee78)która wskazuje na string aaa.

Dlaczego stringi są niezmienne i co z tego wynika?

 <suchar>Niestety zajmiemy się mniej namacalną implementacją stringów</suchar>  ;)

Typ string (System.String) służy do reprezentacji łańcuchów tekstowych w postaci sekwencji wartości typu char (System.Char) określających znaki Unicode (zakodowane w UTF-16). Zazwyczaj jeden element char koduje jeden znak...

Przy pracy z ciągami tekstowymi należy pamiętać, że stringi w .NET są niezmienne (immutable)! Oznacza to po prostu, że raz utworzony łańcuch tekstowy nie może być modyfikowany (bez użycia refleksji lub kodu unsafe), a metody pozornie modyfikujące string, tak naprawdę zwracają nowy obiekt mający żądaną wartość.

Niezmienność stringów ma wiele zalet (o tym za chwilę), może jednak być źródłem problemów jeśli programista zapomni, że każda "zmiana" łańcucha tekstowego to tak naprawdę tworzenie nowej instancji klasy String. Chociaż CLR traktuje stringi w szczególny sposób, nadal są one typem referencyjnym, dla których to pamięć przydzielana jest na zarządzanej stercie.

Działanie tej pętli spowoduje utworzenie 10 tysięcy zmiennych typu string, z których wszystkie prócz ostatniej to śmieci, które będzie musiał zebrać Garbage Collector:

string s = string.Empty;

for (int i = 0; i < 10000; i++)
{
    s += "x";
}

Na poniższym obrazie widać fragment okna "Histogram by Size for Allocated Objects" aplikacji CLR Profiler. Widać jak kolejne obroty pętli powodowały alokacje pamięci na stercie dla coraz większych stringów:

By uniknąć tworzenia wielu niepotrzebnych obiektów należy użyć klasy StringBuilder, która umożliwia modyfikację tekstu bez każdorazowego tworzenia nowych obiektów:

StringBuilder sb = new StringBuilder();

for (int i = 0; i < 10000; i++)
{
    sb.Append("x");
}

string x = sb.ToString();

Ta prosta zmiana ma ogromny wpływ na ilość przydzielanej i zwalnianej pamięci. Spójrz na poniższe porównanie fragmentów okien "Summary" profilera:

 

Dlaczego projektanci .NET (tak samo jak np. twórcy Javy) zdecydowali się zaimplementować niezmienne łańcuch tekstowe?

Z przyczyn optymalizacyjnych (głównie ze względu na szybkość porównywania) łańcuchy tekstowe mogą być zapisywane w specjalnej tabeli (intern pool) utrzymywanej przez CLR. Chodzi o to by uniknąć tworzenia wielu zmiennych określających ten sam ciąg znaków. Poniżej przedstawiony jest kawałek kodu dowodzący tego, że zmienne posiadające ten sam łańcuch tekstowy mogą wskazywać na ten sam* obiekt:

string a = "xx";
string b = "xx";
string c = "x";
string d = String.Intern(c + c);

Console.WriteLine((object)a == (object)b); // True
Console.WriteLine((object)a == (object)d); // True

Gdyby łańcuchy tekstowe były modyfikowalne, zmieniając wartość zmiennej a, zmieniłoby się też wartość b oraz d.

Niezmienność stringów ma też pozytywne znaczenia w aplikacjach wielowątkowych - zmiana tekstu to utworzenie nowej zmiennej więc nie ma konieczności zakładania blokady (lock) w celu uniknięcia konfliktów związanych z jednoczesnym dostępem wielu wątków do jednego łańcucha tekstowego. Ma to tym większe znaczenie, że często dokonuje się autoryzacji pewnych operacji w zależności od tekstu (np. można blokować szczególne funkcjonalności usługi bazując na stringowym adresie klienta).

Ważnym powodem niezmienności jest powszechne użycie stringów jako kluczy w tablicach haszujących. Jaki sens miało by wyliczenie położenia elementu w tablicy, gdyby można było zmodyfikować warto��ć użytego klucza? Poniższy listing dowodzi, że "zmiana" wartości zmiennej użytej jako klucz nie ma wpływu na działanie tablicy:

string key = "abc";
Hashtable ht = new Hashtable();
ht.Add(key, 123);

key = "xbc";

Console.WriteLine(key); // xbc
Console.WriteLine(ht["abc"]); // 123

O tym co stałoby się w przypadku modyfikowalnych łańcuchów tekstowych można się przekonać za pomocą kodu używającego bloku unsafe w celu rzeczywistej zmiany wartości stringa użytego jako klucz:

unsafe
{
    string key = "abc";
    Hashtable ht = new Hashtable();
    ht.Add(key, 123);

    fixed (char* p = key)
    {
        p[0] = 'x';
    }

    Console.WriteLine(key); // xbc
    Console.WriteLine(ht["abc"]); // Nie znajdzie!
}

Niezmienność wiąże się też z tym, że string wewnętrznie przechowywany jest jako tablica, czyli struktura danych reprezentującą ciągłą przestrzeń adresową (dla której ze względów wydajnościowych nie dopuszcza się np. operacji wstawiania elementu).

* To czy literał łańcuchowy jest automatycznie dodawany do puli może być zależne od użycia narzędzia Ngen.exe lub ustawień CompilationRelaxations...

Wysyłanie komunikatu do WebSphere MQ w UTF-8

Jeśli chcesz wysłać do kolejki WebSphere MQ tekst zakodowany w standardzie UTF-8, pamiętaj o ustawieniu właściwości CharacterSet obiektu MQMessage na 1208. Jeśli tego nie zrobisz, tekst zostanie zakodowany z użyciem UTF-16 (CCSID 1200).

MQQueueManager queueManager = new MQQueueManager(...);
MQQueue queue = queueManager.AccessQueue(...);
MQPutMessageOptions putMessageOptions = new MQPutMessageOptions(...);
MQMessage message = new MQMessage();

message.Format = MQC.MQFMT_STRING;
message.CharacterSet = 1208;
message.WriteString("abcąćę");
queue.Put(message, putMessageOptions);

Stringi w .NET kodowane są przy użyciu UTF-16. Czasem jednak warto do wymiany informacji zastosować kodowanie UFT-8. Dlaczego? Wersja 8 jest oszczędniejsza, ponieważ znaki z tabeli US-ASCII są kodowane za pomocą 1 bajta, a nie za pomocą 2, jak w przypadku UTF-16. Jeśli wiec będziesz przesyłał tekst składający się jedynie z tego zestawu znaków, zużyjesz dwa razy mniej miejsca! W przypadku polskich liter znaki zostaną zakodowane na 2 bajtach (tak jak w UTF-16).

Oto porównanie bajtów dla tekstu "abcąćę":

UTF-8    61 62 63 C4 85 C4 87 C4 99
UTF-16   61 00 62 00 63 00 05 01 07 01 19 01