Притворство строки.NET является типом значения

Конструкция string s была намеренно такой, что вам не нужно слишком сильно беспокоиться об этом как программисту. Во многих ситуациях это означает, что вы можете просто присваивать, перемещать, копировать, изменять строки, не задумываясь о возможных сложных последствиях, если другая ссылка на вашу строку существовала и была бы изменена одновременно (как это происходит со ссылками на объекты).

Строковые параметры в вызове метода

(РЕДАКТИРОВАТЬ: этот раздел добавлен позже)
Когда строки передаются в метод, они передаются по ссылке. Когда они читаются только в теле метода, ничего особенного не происходит. Но когда они изменяются, создается копия, и временная переменная используется в остальной части метода. Этот процесс называется копированием при записи .

Младших беспокоит то, что они привыкли к тому, что объекты являются ссылками, и они изменяются в методе, который изменяет переданный параметр. Чтобы сделать то же самое со строками, им необходимо использовать ключевое слово ref . Это фактически позволяет изменить ссылку на строку и вернуть ее вызывающей функции. Если вы этого не сделаете, строка не может быть изменена телом метода:

void ChangeBad(string s)      { s = "hello world"; }
void ChangeGood(ref string s) { s = "hello world"; }

// in calling method:
string s1 = "hi";
ChangeBad(s1);       // s1 remains "hi" on return, this is often confusing
ChangeGood(ref s1);  // s1 changes to "hello world" on return

On StringBuilder

Это различие важно, но начинающим программистам обычно лучше не знать об этом слишком много. Использование StringBuilder , когда вы много строите строки, - это хорошо, но часто ваше приложение будет иметь гораздо больше проблем, а небольшой прирост производительности StringBuilder незначителен. Остерегайтесь программистов, которые говорят вам, что все манипуляции со строками должны выполняться с использованием StringBuilder.

В качестве очень грубого практического правила: StringBuilder требует некоторых затрат на создание, но добавление стоит недорого. Стоимость создания строки низкая, но объединение обходится относительно дорого. Переломный момент составляет около 400-500 конкатенаций, в зависимости от размера: после этого StringBuilder становится более эффективным.

Подробнее о StringBuilder и производительности строк

РЕДАКТИРОВАТЬ: на основе комментария Конрада Рудольфа, я добавил это section.

Если предыдущее эмпирическое правило заставляет вас задуматься, String.Format , ToString и другие строковые операции, использование StringBuilder в таких случаях вряд ли когда-либо эффективно.

Итак, когда это эффективно? В случаях, когда добавляется много маленьких строк, например, для сериализации данных в файл, и когда вам не нужно изменять «записанные» данные после «записи» в StringBuilder. И в тех случаях, когда многим методам нужно что-то добавлять, потому что StringBuilder является ссылочным типом, а строки копируются при их изменении.

Об интернированных строках

Проблема возникает - не только с младшими программистами - когда они пытаются сделать эталонное сравнение и выясните, что иногда результат верный, а иногда ложный в, казалось бы, одних и тех же ситуациях. Что случилось? Когда строки были интернированы компилятором и добавлены в глобальный статический интернированный пул строк, сравнение двух строк может указывать на один и тот же адрес памяти. Когда (ссылка!) Сравнение двух равных строк, одна интернированная, а другая нет, даст false. Используйте сравнение = или Equals и не экспериментируйте с ReferenceEquals при работе со строками.

On String.Empty

В той же лиге соответствует странному поведению, которое иногда происходит при использовании String.Empty : статический String.Empty всегда интернируется, а переменная с присвоенным значением - нет. Однако по умолчанию компилятор назначит String.Empty и укажет на тот же адрес памяти. Результат: изменяемая строковая переменная, по сравнению с ReferenceEquals , возвращает true, в то время как вы можете ожидать вместо этого false.

// emptiness is treated differently:
string empty1 = String.Empty;
string empty2 = "";
string nonEmpty1 = "something";
string nonEmpty2 = "something";

// yields false (debug) true (release)
bool compareNonEmpty = object.ReferenceEquals(nonEmpty1, nonEmpty2);

// yields true (debug) false (release, depends on .NET version and how it's assigned)
bool compareEmpty = object.ReferenceEquals(empty1, empty2);

Подробно

Вы в основном спрашивали, какие ситуации могут возникнуть у непосвященных. Я думаю, что моя точка зрения сводится к тому, чтобы избегать object.ReferenceEquals , потому что ему нельзя доверять при использовании со строками. Причина в том, что интернирование строки используется, когда строка является постоянной в коде, но не всегда. На такое поведение нельзя полагаться. Хотя String.Empty и "" всегда интернированы, это не так, когда компилятор считает, что значение можно изменить. Различные варианты оптимизации (отладка против выпуска и другие) дадут разные результаты.

Когда сделать , вам все равно понадобится ReferenceEquals ? С объектами это имеет смысл, но со строками - нет.