Коли використовувати ref і коли це не потрібно в C #

У мене є об'єкт, який є моїм в пам'яті програми, а також я маю деякі інші робочі функції, які я передаю об'єкту для зміни стану. Я передаю це по службовим функціям. Однак я натрапив на наступну функцію.

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); 

Це мене бентежить, тому що і те, received_sі remoteEPповертають речі з функції. Для чого remoteEPпотрібен refа received_sчи ні?

Я також програміст змінного струму, тому у мене виникають проблеми з виведенням вказівників з голови.

Редагувати: Схоже, що об'єкти в C # є вказівниками на об'єкт під кришкою. Отже, коли ви передаєте об'єкт функції, ви можете змінювати вміст об'єкта через покажчик, і єдине, що передається функції, - це вказівник на об'єкт, тому сам об'єкт не копіюється. Ви використовуєте ref або out, якщо хочете мати можливість вимкнути або створити новий об'єкт у функції, яка є як подвійний вказівник.

Коротка відповідь: прочитайте мою статтю про передачу аргументів .

Довга відповідь: коли параметр типу посилання передається за значенням, передається тільки посилання, а не копія об'єкта. Це як передача вказівника (за значенням) на C або C ++. Зміни в вартості самого параметра не буде видно викликає, але зміни в об'єкті якої опорні точки , щоб буде видно.

Коли параметр (будь-якого виду) передається з допомогою посилання, це означає , що будь-які зміни параметра помічені викликає - зміни параметра є зміни в змінної.

Стаття пояснює все це більш докладно, звичайно :)

Корисна відповідь: вам майже ніколи не потрібно використовувати перемикання / вимкнення . Це, в основному, спосіб отримати ще одне повернене значення, і його, як правило, слід уникати саме тому, що це означає, що метод, ймовірно, намагається зробити занадто багато. Це не завжди так ( TryParseі т. Д. - канонічні приклади розумного використання out), але використання відсилки / виходу повинно бути відносно рідкістю.

Подумайте про параметр non ref, як на вказівник, а параметр ref як на подвійний покажчик. Це мені найбільше допомогло.

Ви майже ніколи не повинні передавати значення за посиланням. Я підозрюю, що якби не проблеми інтеропа, команда .Net ніколи б не включила його в оригінальну специфікацію. OO спосіб вирішення більшості проблем, які вирішують параметри ref, полягає в:

Для кількох повернених значень

• Створіть структури, які представляють кілька повернених значень

Для примітивів, які змінюються в результаті в результаті виклику методу (метод має побічні ефекти на примітивні параметри)

• Реалізація методу в об'єкті як метод екземпляра та маніпулювання станом об'єкта (а не параметрами) як частини виклику методу
• Скористайтеся рішенням із множинним поверненням і об'єднайте повернені значення зі своїм станом
• Створіть об’єкт, який містить стан, яким можна керувати методом, і передайте цей об'єкт як параметр, а не самі примітиви.

Ви, ймовірно, можете написати цілий додаток C # і ніколи не передавати об'єкти / структури за посиланням.

У мене був професор, який мені це сказав:

Єдине місце, де ви б використовували рефлекси, це те, де ви:

1. Хочете передати великий об'єкт (тобто об'єкти / структура має об'єкти / структури всередині нього на декілька рівнів), і копіювати його було б дорого і
2. Ви викликаєте Framework, API API або інший API, який цього вимагає.

Не робіть цього лише тому, що можете. Ви можете покусати в дупу деякими неприємними помилками, якщо почнете змінювати значення в параметрі і не звернете уваги.

Я погоджуюся з його порадою, і за мої п’ять плюс років, починаючи зі школи, у мене ніколи не було потреби в тому, щоб закликати Framework або API API.

Оскільки получен_с є масивом, ви передаєте вказівник на цей масив. Функція маніпулює наявними даними на місці, не змінюючи базове місце чи покажчик. Ключове слово ref означає, що ви передаєте фактичний вказівник на місце розташування та оновлюєте цей покажчик у зовнішній функції, тому значення в зовнішній функції зміниться.

Наприклад, байтовий масив - це вказівник на одну і ту ж пам’ять до і після, пам'ять щойно оновлена.

Посилання на кінцеву точку фактично оновлює вказівник на Кінцеву точку у зовнішній функції до нового екземпляра, згенерованого всередині функції.

Подумайте про перелік як про те, що ви передаєте вказівник за посиланням. Якщо ви не використовуєте ref, ви передаєте вказівник за значенням.

А ще краще ігноруйте те, що я щойно сказав (це, мабуть, вводить в оману, особливо з типами значень) і читайте цю сторінку MSDN .

моє розуміння полягає в тому, що всі об'єкти, похідні від класу Object, передаються як покажчики, тоді як звичайні типи (int, struct) не передаються як покажчики і потребують посилання. Я не впевнений у рядку (це в кінцевому підсумку походить від класу Object?)

Хоча я погоджуюсь із загальною відповіддю Джона Скіта та деякими іншими відповідями, є приклад використання для використання refта посилення оптимізації продуктивності. Під час профілювання продуктивності було помічено, що встановлення значення повернення методу має незначні наслідки для продуктивності, тоді як використання refв якості аргументу повернення значення повернення в цей параметр призводить до усунення цього невеликого вузького місця.

Це дійсно корисно лише тоді, коли зусилля з оптимізації докладаються до крайніх рівнів, приносячи в жертву читабельність і, можливо, передбачуваність та ремонтопридатність для економії мілісекунд або, можливо, розділених мілісекунд.

Спочатку нульове правило, примітиви передаються за значенням (стек) і Непримітивні за посиланням (Heap) в контексті TYPES.

Задіяні параметри передаються значенням за замовчуванням. Хороший пост, який детально пояснює речі. 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
}

Можна сказати (з попередженням) Non-примітивні типи нічого , крім покажчиків І коли ми передаємо їх вих ми можемо сказати , що ми проходимо Подвійний покажчик