Kiedy używać ref, a kiedy nie jest to konieczne w C #

Mam obiekt, który jest moim stanem pamięci programu, a także kilka innych funkcji roboczych, do których przekazuję obiekt, aby zmodyfikować stan. Przekazywałem to przez odwołanie do funkcji robotniczych. Jednak natrafiłem na następującą funkcję.

byte[] received_s = new byte[2048];
IPEndPoint tmpIpEndPoint = new IPEndPoint(IPAddress.Any, UdpPort_msg);
EndPoint remoteEP = (tmpIpEndPoint);

int sz = soUdp_msg.ReceiveFrom(received_s, ref remoteEP); 

To mnie dezorientuje, ponieważ oba received_si remoteEPzwracają rzeczy z funkcji. Dlaczego remoteEPpotrzebujemy refi received_snie robi?

Jestem też programistą AC, więc mam problem z wyrzuceniem wskaźników z mojej głowy.

Edycja: wygląda na to, że obiekty w C # są wskaźnikami do obiektu pod maską. Więc kiedy przekazujesz obiekt do funkcji, możesz następnie zmodyfikować zawartość obiektu za pomocą wskaźnika, a jedyną rzeczą przekazaną do funkcji jest wskaźnik do obiektu, aby sam obiekt nie był kopiowany. Używasz ref lub out, jeśli chcesz mieć możliwość przełączania się lub tworzenia nowego obiektu w funkcji, który jest podobny do podwójnego wskaźnika.

Krótka odpowiedź: przeczytaj mój artykuł o przekazywaniu argumentów .

Długa odpowiedź: gdy parametr typu odwołania jest przekazywany przez wartość, przekazywane jest tylko odwołanie, a nie kopia obiektu. Jest to podobne do przekazywania wskaźnika (według wartości) w C lub C ++. Zmiany wartości samego parametru nie będą widoczne dla wywołującego, ale zmiany w obiekcie, na który wskazuje odniesienie, będą widoczne.

Gdy parametr (dowolnego rodzaju) jest przekazywany przez referencję, oznacza to, że wszelkie zmiany parametru są widoczne dla wywołującego - zmiany parametru są zmianami w zmiennej.

Oczywiście artykuł wyjaśnia to wszystko bardziej szczegółowo :)

Przydatna odpowiedź: prawie nigdy nie musisz używać ref / out . Jest to po prostu sposób na uzyskanie kolejnej wartości zwracanej i zwykle należy go unikać właśnie dlatego, że oznacza to, że metoda prawdopodobnie próbuje zrobić za dużo. Nie zawsze tak jest ( TryParseitp. Są kanonicznymi przykładami rozsądnego użycia out), ale używanie ref / out powinno być stosunkowo rzadkie.

Pomyśl o parametrze innym niż ref jako wskaźniku, a parametrze ref jako o podwójnym wskaźniku. To mi najbardziej pomogło.

Prawie nigdy nie powinieneś przekazywać wartości przez ref. Podejrzewam, że gdyby nie problemy związane z interopem, zespół .Net nigdy nie umieściłby tego w oryginalnej specyfikacji. Sposobem OO rozwiązania większości problemów, które rozwiązują parametry ref, jest:

Dla wielu wartości zwracanych

• Utwórz struktury, które reprezentują wiele zwracanych wartości

Dla prymitywów, które zmieniają się w metodzie w wyniku wywołania metody (metoda ma skutki uboczne w parametrach pierwotnych)

• Zaimplementuj metodę w obiekcie jako metodę instancji i manipuluj stanem obiektu (nie parametrami) w ramach wywołania metody
• Użyj rozwiązania z wieloma wartościami zwracanymi i scal wartości zwracane ze swoim stanem
• Utwórz obiekt, który zawiera stan, którym można manipulować metodą, i przekaż ten obiekt jako parametr, a nie same prymitywy.

Prawdopodobnie możesz napisać całą aplikację C # i nigdy nie przekazywać żadnych obiektów / struktur przez ref.

Miałem profesora, który powiedział mi to:

Jedyne miejsce, w którym użyjesz referencji, to miejsce, w którym:

1. Chcesz przekazać duży obiekt (tj. Obiekty / struktura ma w sobie obiekty / struktury na wiele poziomów), a skopiowanie go byłoby kosztowne i
2. Wzywasz Framework, Windows API lub inny API, który tego wymaga.

Nie rób tego tylko dlatego, że możesz. Możesz zostać ugryziony w tyłek przez jakieś paskudne błędy, jeśli zaczniesz zmieniać wartości w parametrze i nie zwracasz na to uwagi.

Zgadzam się z jego radą i przez ponad pięć lat, które minęły od szkoły, nigdy nie potrzebowałem tego poza wywoływaniem Framework lub Windows API.

Ponieważ otrzymane_s jest tablicą, przekazujesz wskaźnik do tej tablicy. Funkcja manipuluje istniejącymi danymi w miejscu, nie zmieniając podstawowej lokalizacji ani wskaźnika. Słowo kluczowe ref oznacza, że ​​przekazujesz rzeczywisty wskaźnik do lokalizacji i aktualizujesz ten wskaźnik w funkcji zewnętrznej, więc wartość w funkcji zewnętrznej ulegnie zmianie.

Np. Tablica bajtów jest wskaźnikiem do tej samej pamięci przed i po, pamięć została właśnie zaktualizowana.

Odwołanie do punktu końcowego w rzeczywistości aktualizuje wskaźnik do punktu końcowego w funkcji zewnętrznej do nowego wystąpienia wygenerowanego wewnątrz funkcji.

Pomyśl o odnośniku jako o tym, że przekazujesz wskaźnik przez odniesienie. Nieużywanie ref oznacza, że ​​przekazujesz wskaźnik według wartości.

Jeszcze lepiej, zignoruj ​​to, co właśnie powiedziałem (prawdopodobnie wprowadza w błąd, szczególnie w przypadku typów wartości) i przeczytaj tę stronę MSDN .

rozumiem, że wszystkie obiekty wywodzące się z klasy Object są przekazywane jako wskaźniki, podczas gdy typy zwykłe (int, struct) nie są przekazywane jako wskaźniki i wymagają ref. Nie jestem pewien co do ciągu (czy ostatecznie pochodzi z klasy Object?)

Chociaż ogólnie zgadzam się z odpowiedzią Jona Skeeta i niektórymi innymi odpowiedziami, istnieje przypadek użycia ref, który służy do zaostrzenia optymalizacji wydajności. Podczas profilowania wydajności zaobserwowano, że ustawienie wartości zwracanej metody ma niewielki wpływ na wydajność, podczas gdy użycie refjako argumentu, w którym wartość zwracana jest umieszczana w tym parametrze, powoduje usunięcie tego niewielkiego wąskiego gardła.

Jest to naprawdę przydatne tylko wtedy, gdy wysiłki optymalizacyjne są podejmowane na skrajnych poziomach, poświęcając czytelność, a być może testowalność i łatwość konserwacji, aby zaoszczędzić milisekundy lub może ułamek milisekund.

Najpierw reguła punktu zerowego, prymitywy są przekazywane przez wartość (stos), a nie-prymitywne przez odwołanie (sterta) w kontekście zaangażowanych TYPÓW.

Uwzględnione parametry są domyślnie przekazywane przez wartość. Dobry post, który szczegółowo wyjaśnia wszystko. http://yoda.arachsys.com/csharp/parameters.html

Student myStudent = new Student {Name="A",RollNo=1};

ChangeName(myStudent);

static void ChangeName(Student s1)
{
  s1.Name = "Z"; // myStudent.Name will also change from A to Z
                // {AS s1 and myStudent both refers to same Heap(Memory)
                //Student being the non-Primitive type
}

ChangeNameVersion2(ref myStudent);
static void ChangeNameVersion2(ref Student s1)
{
  s1.Name = "Z"; // Not any difference {same as **ChangeName**}
}

static void ChangeNameVersion3(ref Student s1)
{
    s1 = new Student{Name="Champ"};

    // reference(myStudent) will also point toward this new Object having new memory
    // previous mystudent memory will be released as it is not pointed by any object
}

Możemy powiedzieć (z ostrzeżeniem) Typy niebędące prymitywami to nic innego jak wskaźniki A kiedy mijamy je przez ref możemy powiedzieć, że przechodzimy przez Double Pointer