Привет, Хабр!
Наверняка вы сталкивались с out, ref и in, но вот в чём штука — хотя выглядят они похоже, под капотом у них совершенно разные намерения. Один любит брать всё на себя, другой ждёт готового, третий — как библиотекарь: знает много, но не вмешивается. Сегодня разберёмся, когда и кого стоит звать в метод
Зачем нужны ref, in и out?
Часто в C# методах мы передаём параметры «по значению» (by value). Это значит, что внутри метода у нас есть копия значения, а не сама переменная, которую туда подкинули. И если мы эту копию меняем, то внешняя переменная остаётся нетронутой.
Однако бывает, что нужно передавать сам объект или само значение, чтобы изменение внутри метода влияло и на то, что происходит снаружи. Допустим, вы вызываете метод, который должен заполнить вашу переменную данными, а переменная объявлена «снаружи» (в коде, который вызвал метод). Для таких сценариев в C# есть три способа: out, ref и более новый in.
И хотя все три — это «передача по ссылке», у каждого своя специфика, свои ограничения и тонкости. Сразу по сути:
out — используется для передачи пустой (или неинициализированной) переменной, которую метод заполнит и вернёт.
ref — параметр уже инициализирован, и метод может как читать, так и менять его.
in — параметр передаётся в метод по ссылке, но только для чтения (внутри метода нельзя менять значение).
out: метод сам заполнит вам переменную
out как будто говорит: «Передай мне переменную, но я сам решу, что в неё записать, и верну её в готовом виде». Причём переменная, которую вы передаёте на вход с out, не обязана иметь изначально какое‑то значение — главное, чтобы компилятор был доволен, что метод до выхода обязательно инициализирует её.
Работает это таким образом:
Переменная, обозначенная словом
outпри вызове метода, должна быть объявлена, но не обязательно инициализирована.В самом методе, где принимается параметр
out, в теле обязательно должны быть присвоены конкретные значения (компилятор не даст скомпилировать, если какой‑то путь выполнения оставляет переменную неинициализированной).По завершении метода переменная (уже с каким‑то значением) вернётся наружу.
Пример:
// Допустим, хочется распарсить строку в int,
// но сами не хотим возиться с TryParse,
// а сделаем свой метод.
bool TryParseCustom(string input, out int result)
{
// Инициализируем result чем-то обязательно
// (или в любом случае на каждом пути).
result = 0;
if (string.IsNullOrEmpty(input))
{
return false;
}
// Пытаемся конвертировать
try
{
result = Convert.ToInt32(input);
return true;
}
catch
{
return false;
}
}
// Как пользоваться:
public void ExampleOutUsage()
{
// Переменная объявлена, но не инициализирована
// (Это можно, ведь мы планируем использовать out)
int number;
// Передаём её в метод
bool success = TryParseCustom("123", out number);
if (success)
{
Console.WriteLine($"Парсинг удался, результат: {number}");
}
else
{
Console.WriteLine("Не удалось распарсить");
}
}Нужно помнить, что перед использованием такой переменной снаружи её надо инициализировать внутри метода. Если метод возвращает значения по out, это иногда сложнее тестировать и понимать, чем очевидный возврат через return (или кортеж). С другой стороны, это уже устоявшийся паттерн в.NET (см. int.TryParse, например).
ref: инициализация на совести вызывающего кода
ref — это уже старый добрый вариант передачи по ссылке, который говорит: «У меня уже есть значение, но передаю его по ссылке, чтобы внутри метода его можно было изменить».
Переменная, которую вы пометили ref, должна быть инициализирована до вызова метода. Метод, принимающий параметр ref, может и читать, и менять значение параметра.
Пример:
public void IncreaseValue(ref int value)
{
// Можно прочитать
Console.WriteLine($"Текущее значение: {value}");
// Можно изменить
value += 10;
}
public void ExampleRefUsage()
{
int myNumber = 5;
Console.WriteLine($"До вызова метода: {myNumber}");
IncreaseValue(ref myNumber);
Console.WriteLine($"После вызова метода: {myNumber}");
// Результат: myNumber теперь равен 15
}Передача по ref вносит в код императивную нить: вызывающий код может не сразу понять, что значение будет изменено внутри. Нужно хорошо документировать.
А если вы передаёте какую‑то переменную по ref и параллельно кто‑то ещё работает с ней, можно получить непредсказуемый результат. Либо будьте уверены, что потоки синхронизируются, либо избегайте ref в таких сценариях.
in: только для чтения, но по ссылке
in — это более новый параметр, который ввели в C# 7.2. Он говорит: «Я хочу передать значение по ссылке, но только для чтения». Т.е метод не может изменить эту переменную, а компилятор будет ругаться, если мы попытаемся присвоить ей что‑то другое.
Это штука исключительно полезная, когда:
Нужны преимущества передачи больших структур по ссылке (без копирования).
Хочется гарантировать, что никто не изменит структуру внутри метода.
Как это работает
Вы объявляете параметр как
in.Вызов метода может передавать переменную как
in, компилятор строго следит, чтобы внутри метода параметр не менялся.При этом передача по ссылке сокращает накладные расходы копирования, если структура большая.
Пример:
public struct LargeStruct
{
// Вообразим, что здесь много полей, и копировать их при каждом вызове — накладно
public int A;
public int B;
public double C;
// ... и так далее
}
public static double CalculateSomeValue(in LargeStruct data)
{
// Мы имеем доступ к параметру data,
// но по правилам in не можем менять его поля.
return data.A + data.B * data.C;
}
public void ExampleInUsage()
{
var bigData = new LargeStruct { A = 2, B = 5, C = 3.14 };
double result = CalculateSomeValue(in bigData);
Console.WriteLine($"Результат расчёта: {result}");
// Результат может быть 2 + 5*3.14 = 2 + 15.7 = 17.7
}Если внутри метода всё же хочется изменить параметр (например, присвоить ему новое значение), компилятор не даст: «Нельзя же, это in!». В таком случае либо убирайте in, либо делайте копию (да, копии не всегда хочется).
А если структуру передать по in, и внутри метода вызвать другие методы, которые принимают параметр по значению (или не умеют работать с in), может произойти неявное копирование структуры. Это небольшой «подводный камень», потому что иногда люди думают, что никакого копирования нет, а оно всё‑таки случается за кулисами, когда вы вызываете обычные методы, не принимающие in.
Сравнительная таблица
Чтобы наглядно свести воедино:
Обязательна ли инициализация «на входе»? | Можно ли менять внутри метода? | Для чего подходит? | |
|---|---|---|---|
out | Нет (метод сам инициализирует) | Да, обязательно (иначе ошибка) | Для возвращения значения наружу, когда оно было «пустое» |
ref | Да (переменная уже что‑то хранит) | Да | Когда нужно читать и менять существующую переменную |
in | Да (переменная инициализирована) | Нет (только для чтения) | Для оптимизации (передача больших структур без копирования) и гарантий неизменности |
Пример оптимизации обработки больших структур
Допустим, есть какая‑то довольно массивная структура Matrix (например, 4×4 матрица для 3D‑преобразований). Мы собираемся в игре или в научных расчётах очень много раз её преобразовывать. Чтобы не гонять по 1000 раз копии одной и той же матрицы (что может съедать кучу CPU), мы используем in.
public struct Matrix
{
public float M11, M12, M13, M14;
public float M21, M22, M23, M24;
public float M31, M32, M33, M34;
public float M41, M42, M43, M44;
// Предположим, что здесь много методов, и структура реально большая
}
public static class MatrixMath
{
public static float CalculateDeterminant(in Matrix matrix)
{
// Компилятор гарантирует, что мы не сможем присвоить matrix что-то другое
// ... Пример кода детерминанта опущу, но смысл ясен:
// мы лазим по M11, M12... ничего не копируя
// Возвращаем результат, используя поля.
// (Здесь для краткости ограничимся скелетом)
return matrix.M11 * matrix.M22 - matrix.M12 * matrix.M21;
}
}
public class MatrixUsage
{
public void ProcessMatrix()
{
var bigMatrix = new Matrix
{
M11 = 1f, M12 = 2f, M13 = 0.5f, M14 = 0f,
M21 = 0f, M22 = 1f, // и так далее
};
// Вызываем
float determinant = MatrixMath.CalculateDeterminant(in bigMatrix);
Console.WriteLine($"Детерминант: {determinant}");
}
}Здесь, казалось бы, ничего особо сложного, но при частых вызовах методы с in позволяют экономить на копировании больших структур.
Но даже если мы используем in, где метод не меняет значение, нужно помнить, что кто‑то другой может менять эту же переменную (если это не readonly struct и не readonly поля). Слово in защищает только внутри данного метода, но не контролирует внешние параллельные изменения.
Заключение
Как видим, ref, in и out — это три, казалось бы, похожих механизма, но каждый олицетворяет свою маленькую философию в C#. out рождает значения и передаёт наружу, ref позволяет менять уже готовое, а in говорит: «Я большой, но меня не надо копировать, и не смейте меня трогать.».
Хочется отдельно подчеркнуть, что часто вообще забывают про in, либо боятся ref. Но если вы понимаете сценарии, зачем вы их используете, то код получается надёжнее.
Если вам важно не только разобраться в нюансах передачи параметров в C#, но и углубить свои знания в области работы с данными и архитектурой систем, рекомендую обратить внимание на следующие открытые уроки. Каждый из них предлагает уникальный взгляд на эффективное управление данными и разработку высокопроизводительных решений.
Выстраивание архитектуры мониторинга инфраструктуры организации с использованием SIEM-систем (23 апреля, 20:00)
Реактивное программирование и MVVM в Unity (29 апреля, 19:00)
Docker для инженера данных (29 апреля, 20:00)