Вот утверждение, которое я прочитал вчера про сравнения объектов ссылочного типа в C#:

Object.ReferenceEquals(x,y) возвращает true если, и только если, x и y ссылаются на один и тот же объект.

Правда или нет?

Моя жена Лея недавно купила Хонду Фит, спасибо имманентному отказу в соленоидах автоматической коробки передач её старой Хонды Цивик. Задние сиденья Фита складываются в плоскость. В эту штуку можно загнать ламу, или целую кучу хула-хупов, или всё что угодно. Это весьма удобно. Не то, что я называю мощным движком, но для быстрых поездок по городу она – то, что надо.

Поскольку мы были женаты, когда она купила машину, и продолжаем состоять в браке, что моё – то её, и что её – то моё. Так что если x = Хонда Фит Эрика, а y = Хонда Фит Леи, то x и y «ссылочно эквивалентны». Эти две вещи ссылаются на один и тот же объект, тот блестящий чёрный объект, полный лам и хула-хупов, который стоит возле моего дома.

Теперь, мы могли купить другую машину. Скажем, Форд Фокус. Но мы не купили. У нас в сумме ноль Фордов Фокусов. Предположим, я сказал, что x = Форд Фокус Эрика, а y = Форд Фокус Леи. Каков осмысленный способ охарактеризовать природу x и y? Должны ли мы сказать, что обе они ссылаются на один и тот же Форд Фокус, а именно на несуществующий Форд Фокус? Разум колеблется от неприемлемого и парадоксального предположения о том, что где-то существует Форд Фокус, который является несуществующим Фордом Фокус!(*) Скорее, верный способ охарактеризовать это в том, чтобы сказать, что ни x ни y не ссылаются ни на какой объект. Это «пустые ссылки» - ссылки, которые ни на что не ссылаются, а, скорее, имеют значение «отсутствия ссылаемого».

И именно поэтому неверно говорить, что Object.ReferenceEquals(x,y) возвращает true если, и только если, x и y ссылаются на один и тот же объект. Если x и y не ссылаются на объекты, то они явно не ссылаются на один и тот же объект, потому что никто из них не ссылается на объект вообще. Корректный способ охарактеризовать поведение ссылочной эквивалентности в том, что Object.ReferenceEquals(x,y) возвращает true если, и только если, либо x и y ссылаются на один и тот же объект, либо и x и y – пустые ссылки.

***********

(*) И я по-прежнему фанат «null object pattern». Жизнь полна этих маленьких противоречий.

[Эрик на этой неделе в отпуске, пост был предварительно записан]

Предостережение: я не эксперт по многопоточному программированию. На самом деле, я бы даже не стал утверждать, что я в нём компетентен. За всю мою карьеру, необходимость написать код, который запускает второй рабочий поток, возникала, вероятно, менее полудюжины раз. Так что воспринимайте всё, что я пишу на эту тему, с некоторым скептицизмом.

Вопрос, который мне часто задают: «потокобезопасен ли этот код?». Для ответа на этот вопрос, нам явно нужно знать, что означает «потокобезопасен».

Но, есть кое-что, что я хочу прояснить перед тем, как мы погрузимся в это. Вопрос, который мне задают значительно реже – «Эрик, почему Мишель Пфайфер всегда так хорошо выглядит на фотографиях?» За помощью в ответе на этот животрепещущий вопрос я обратился к Википедии:

«Фотогеничный субъект – это субъект, который обычно оказывается физически привлекательным или красивым на фотографиях.»

Почему Мишель Пфайфер всегда так хорошо выглядит на фотографиях? Потому, что она фотогенична. Очевидно.

Ну, хорошо, что мы разгадали эту тайну, но, похоже, я несколько отклонился от предмета обсуждения. Википедия столь же полезна в определении потокобезопасности:

«Код потоково-безопасный, если он функционирует корректно при использовании из нескольких потоков одновременно.»

Как и с фотогеничностью, это очевидно, провоцирует вопросы. Когда мы спрашиваем «является ли этот код потокобезопасным?», то на самом деле мы хотим узнать «является ли этот код корректным, будучи вызван определённым образом?» Так как же мы определим, корректен ли код? Мы, собственно, ничего здесь не объяснили.

Википедия продолжает:

«В частности, он должен обеспечивать корректный доступ нескольких потоков к разделяемым данным»

Это выглядит честным; этот сценарий почти всегда и есть то, что люди имеют в виду, говоря о потокобезопасности. Но затем:

«и обеспечивать доступ к фрагменту разделяемых данных только одному потоку в каждый момент времени.»†

Теперь мы говорим о техниках обеспечения потокобезопасности, а не об определении того, что означает потокобезопасность. Блокировка данных, так, чтобы к ним мог обращаться только один поток за раз – это только одна из возможных техник обеспечения потокобезопасности; это само по себе не определение потокобезопасности.*

Мой аргумент не в том, что определение неверно; как неформальное определение потокобезопасности это не слишком ужасно. Скорее, мой аргумент в том, что определение показывает что сама концепция абсолютно туманна и, в сущности, означает не более, чем «ведёт себя корректно в некоторых ситуациях». Так что, когда меня спрашивают «потокобезопасен ли этот код?», мне всегда приходится отступать и спрашивать «о каких конкретно многопоточных сценариях вы беспокоитесь?» и «какое конкретно поведение объекта корректно в каждом из этих сценариев?»

Проблемы коммуникации возникают тогда, когда люди с различными ответами на эти вопросы пытаются общаться о потокобезопасности. Например, представьте, что я сказал вам, что у меня есть «потокобезопасная изменяемая очередь», которую вы можете использовать в своей программе. Вы затем радостно пишете следующий код, который выполняется в одном потоке, пока другой поток занят добавлением и удалением элементов из изменяемой очереди:

if (!queue.IsEmpty) Console.WriteLine(queue.Peek());

Затем ваш код падает, когда Peek бросает QueueEmptyException. Что происходит? Я же сказал, что штуковина потокобезопасна, но ваш код всё равно падает в многопоточном сценарии.

Когда я говорил «очередь потокобезопасна», я имел виду, что очередь поддерживает своё внутреннее состояние целостным, независимо от того, каков порядок отдельных операций, выполняемых в других потоках. Но я не имел в виду, что вы можете использовать мою очередь в произвольном сценарии, который требует поддержания логической целостности между несколькими последовательными операциями. Короче, моё мнение насчёт «корректного поведения» и ваше мнение на ту же тему разошлись, потому, что подразумеваемые нами сценарии были совершенно различны. Меня беспокоило только отсутствие сбоев, но вам важно иметь возможность логически рассуждать об информации, возвращаемой из каждого вызова метода.

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

Проблема здесь в том, что выбор, получать ли доступ к первому элементу, основан на «несвежих» данных. Проектирование полностью потокобезопасной изменяемой структуры данных в мире, где ничему не позволено быть устаревшим может быть весьма сложным. Подумайте, что бы вам пришлось сделать, чтобы операция «Peek» выше стала реально потокобезопасной. Вам бы потребовался новый метод:

if (!queue.Peek(out first)) Console.WriteLine(first);

«Потокобезопасно» ли это? Выглядит определённо лучше. Но что, если после Peek, другой поток опустошает очередь? Теперь вы не падаете, но вы значительно изменили поведение предыдущей программы. В предыдущей программе, если после проверки в другом потоке выполнилась операция, изменившая статус первого элемента, то вы либо падали, либо печатали свежий первый элемент очереди. Теперь вы печатаете устаревший первый элемент. Корректно ли это? Нет, если вы хотите всегда оперировать свежими данными!

Но, минуточку – на самом деле, в предыдущей версии кода тоже была эта проблема. Что, если из очереди извлекли элемент в другом потоке после того, как завершился вызов Peek, но до того, как выполнился вызов Console.WriteLine? Опять же, вы бы вывели устаревшие данные.

Что, если вы хотите гарантировать, что всегда печатаете свежие данные? Вот, что нужно вам на самом деле, чтобы сделать это потокобезопасным:

queue.DoSomethingToHead(first=>{Console.WriteLine(first);});

Теперь автор очереди и пользователь очереди договорились о том, какие сценарии нужны, так что это и вправду потокобезопасно. Правильно?

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

Буэ.

Теперь, я уверен, вы поняли, к чему я клоню. Как я указывал ранее, нет смысла говорить, что здание или кусок кода «безопасны» без некоторого описания того, от каких угроз применяемый механизм безопасности защищает, а от каких – нет. Аналогично, нет смысла говорить, что код потокобезопасен без некоторого описания того, какие виды нежелательного поведения предотвращаются применяемыми механизмами потокобезопасности, а какие – нет. «Потокобезопасность» - это ни больше, ни меньше, как контракт кода, как и любой другой контракт кода. Вы соглашаетесь общаться с объектом определённым образом, и он соглашается возвращать вам корректные результаты, если вы так делаете; выяснение того, каков именно этот образ, и что считать корректным результатом, представляет собой потенциально сложную задачу.

************

(†) В русскоязычной Википедии этот фрагмент определения отсутствует, есть в оригинале. – прим. перев.

************

(*) Да, я в курсе, что если я думаю, что что-то в Википедии неверно, то я могу это изменить. Есть две причины, по которым мне не стоит этого делать. Во-первых, как я уже заявил, я не эксперт в этой области; я оставляю экспертам разобраться между собой, что здесь будет правильно сказать. И во-вторых, смысл моего утверждения не в том, что страничка в Википедии неверна, а скорее в том, что она иллюстрирует неопределённость термина по его природе. – Эрик.

Отсутствие доказательств – не доказательство отсутствия

Сегодня – ещё два слегка неверных мифа о C#.

Как вы, вероятно, знаете, C# требует, чтобы всем локальным переменным были явно присвоены значения перед тем, как из них читают, но предполагает, что всем полям экземпляра класса изначально присвоены их значения по умолчанию. Порой я слышу такое объяснение причин этого: «компилятор может легко доказать, что локальная переменная не проинициализирована, но значительно труднее доказать отсутствие инициализации для поля экземпляра. И, поскольку конструктор по умолчанию автоматически инициализирует все поля экземпляра значениями по умолчанию, то для полей проводить анализ не нужно».

Оба утверждения слегка неверны.

Первое утверждение неверно потому, что на самом деле компилятор не способен, и не пытается доказать, что локальная переменная неинициализирована. Доказательство этого (1) невозможно, и (2) не даёт нам никакой полезной информации для следующих действий. Невозможно оно потому, что доказательство наличия присваивания значения заданной переменной эквивалентно решению Задачи Останова:

int x;
if (/*тут условие, требующее решения задачи останова*/) x = 10;
print(x);

Если бы мы хотели доказать, что x неинициализирована, то нам бы во время компиляции пришлось бы доказать ложность условия. Наш компилятор не настолько изощрён!

Но более глубокий момент тут в том, что мы не заинтересованы в уверенном доказательстве того, что x неинициализирована. Мы заинтересованы в уверенном доказательстве того, что x инициализирована! Если мы можем это уверенно доказать, то x «определённо инициализирована». Если мы не можем с уверенностью этого доказать, то x «не является определённо инициализированной». В «определённо неинициализирована» мы заинтересованы постольку, поскольку это более сильная версия утверждения «не определённо инициализирована». Если из x читают в момент, когда она «не определённо инициализирована», то это ошибка.

Так что, мы пытаемся доказать, что x инициализирована, и неспособность доказать это в каждой точке, где происходит чтение x и приводит к порождению ошибки. Эта наспособность может быть вызвана как о честной ошибкой в вашей программе, так и чрезмерной консервативностью нашего анализатора потоков выполнения. Например:

int x, y = 0;
if (0 * y == 0) x = 10;
print(x);

Мы с вами знаем, что x определённо инициализирована, но в C# 3 компилятор осознанно недостаточно умён, чтобы это доказать. (Занятно, что он был достаточно умён в C# 2. Я сломал это, чтобы привести компилятор в соответствие со спецификацией; быть умнее в противоречие спецификации не всегда хорошо.)

Этот пример снова демонстрирует, что мы не доказываем неинициализированность x; если бы мы это доказали, то наша доказывалка содержала бы ошибку, так как мы с вами знаем, что x определённо инициализирована. Скорее, нам не удаётся доказать, что x инициализирована.

Это интересный вариант спора между скептиками и легковерами, который происходит следующим образом: скептик говорит «нет надёжных подтверждений существования йети, так что йети не существует». Легковер отвечает «отсутствие подтверждения не является подтверждением отсутствия; так что да, йети существуют». В обоих случаях, рассуждения с позиций отсутствия надёжных подтверждений редко приносят пользу! Но в нашем случае, именно потому, что нам не хватает надёжных подтверждений, мы и приходим к выводу, что наших знаний недостаточно, чтобы позволить вам читать x.

(Принцип, позволяющий на основе отсутствия надёжного подтверждения сделать предварительное заключение о мифичности йети – «экстраординарные утверждения требуют экстраординарных подтверждений». Разумно предполагать, что экстраординарное утверждение ложно, до получения надёжного подтверждения. Когда чрезвычайно надёжное подтверждение находится для экстраординарного утверждения – например, экстраординарного утверждения о том, что само время замедляется, когда ты движешься быстрее, - то имеет смысл поверить в это экстраординарное утверждение. Чрезвычайно надёжные подтверждения были получены для теории относительности, но не для теории йети.)

Второй миф в том, что конструктор по умолчанию инициализирует поля их значениями по умолчанию. Это можно опровергнуть несколькими аргументами.

Во-первых, класс не обязан иметь конструктор по умолчанию, и тем не менее, его поля всегда обнаруживаются изначально проинициализированными. Если конструктора по умолчанию нет, то кто-то другой должен инициализировать поля.

Во-вторых, даже если у класса есть конструктор по умолчанию, то нет гарантии, что он будет вызван. Может быть использован какой-то другой конструктор.

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

В-четвёртых, конструкторы могут вызвать другие конструкторы; если бы каждый из этих конструкторов инициализировал поля нулями, то это было бы расточительно; мы бы без необходимости переинициализировали уже обнулённые поля.

На самом деле происходит то, что аллокатор памяти CLI гарантирует, что память, выделенная экземпляру класса, будет вся инициализирована нулями до того, как произойдёт вызов конструктора. К моменту, когда запускается конструктор, объект уже свежеобнулён и готов ко всему.

Меня часто спрашивают «парни, вы добавили методы расширения в C# 3, так почему бы не добавить ещё и свойства расширения?»

Хороший вопрос.

Давайте, сначала я чуть поговорю о C# 3.0. Явно главной новостью в C# 3 был LINQ. В некотором смысле, у нас было всего три новых возможности в C# 3:

• всё необходимое для LINQ – неявно типизированные переменные, анонимные типы, лямбда-выражения, методы расширения, инициализаторы объектов и коллекций, конструкторы запросов, деревья выражений, улучшенный вывод типов
• частичные методы
• автоматически реализуемые свойства

Последние два были крошечными по сравнению с пунктами из первой пачки. С точки зрения проектирования, синтаксис и семантика обеих возможностей прямолинейны. С точки зрения реализации, у нас уже были механизмы для устранения вызовов; частичные методы и условные методы – почти одно и то же за кулисами. Авто-свойства также были весьма прямолинейны в анализе и генерации кода. Нагрузка по тестировнию тоже была для них не особенно большой.

Команда C# была «длинным шестом» в 2008 релизе Visual Studio и .NET Framework. Под этим я имею в виду то, что если бы вы взяли количество времени, нужно для выполнения работы, на которую подписалась каждая команда, с учётом численности персонала, всё такое, и сделали шесты пропорциональной этому длины для каждой команды в Developer Division, то шест C# оказался бы самым длинным. Что означает, что у любой другой команды в DevDiv был запас в расписании, но если бы мы отстали на день от своего расписания, то новая студия и CLR тоже были бы выпущены на день позже. Если бы любая другая команда отстала на день, ну, до тех пор, пока это не делало их шест длиннее нашего, у них всё ещё было бы всё в порядке. Внутри нашей команды, при разделе работы между разными её участниками, «длинным шестом» были задачи привязывания лямбд и вывода типов методов, отданные мне. Так что, в некотором смысле, каждый день моего опоздания одначал запаздывание выхода продукта на столько же дней. (Никакого давления!)

К счастью, у нас тут превосходная команда, мы все очень хорошо помогали друг другу в течение этого релиза, подхватывая задачи друг друга при необходимости, и выполнили качественный релиз за долгое время. Моя мысль – в том, что если что-то не было либо необходимым для LINQ, либо маленьким, ортогональным, и легковыбрасываемым в случае необходимости (как остальные две), это выбрасывали немедленно. Ни в коем случае мы не собирались рисковать задержать выход всего продукта для какой-то штуки, которая была бы сразу и сложной и не необходимой. Конечно же, сразу было очевидно, что естественным спутником методов расширения являются свойства расширения. Менее очевидно, по какой-то причине, что события расширения, операторы расширения, конструкторы расширения (также известные, как «паттерн «фабрика»»), и так далее, тоже являются естественными спутниками. Но мы даже не рассматривали вопрос проектирования свойств расширения в C# 3; мы знали, что без них можно обойтись, и они добавят риск в и итак уже рискованное расписание, без привлекательного выигрыша.

Ну, теперь мы дошли до C# 4.

Как я люблю напоминать, ответ на все вопросы вида «почему в продукте X нет возможности Y?» один. Этопотому, что для того, чтобы в продукте была некоторая возможность, эта возможность должна быть

• в первую очередь продумана
• нужна
• спроектирована
• специфицирована
• реализована
• протестирована
• задокументирована
• доставлена потребителям

Мы должны пройти каждый из этих пунктов, иначе – никаких новшеств.

Когда мы начали работать над C# 4, мы составили список всех запросов, о которых мы только слышали. В нём были сотни возможностей. Как я описывал в прошлом году, мы рассортировали тот список по корзинкам «стоит сделать / неплохо бы / плохая идея». Свойства расширения были в корзинке «стоит сделать». Затем мы посмотрели на доступный нам бюджет – который измерялся не столько в долларах, сколько в доступных проектировщиках, разработчиках, тестерах, писателях, и менеджерах, умноженных на доступное время – и определили, что у нас хватит ресурсов на реализацию примерно половины вещей в корзинке «стоит сделать». Так что мы выбросили половину этого. Свойства расширения пережили это урезание. Затем мы спроектировали эту возможность. У нас были многочасовые споры о предполагаемом синтаксисе деклараций, способах «прямого» вызова методов чтения и записи как статических методов, и так далее. Мы придумали и согласовали приемлемый синтаксис, спроектировали семантику, написали черновик спецификации, и начали писать код и планы тестирования.

К моменту, когда код дошёл до приличного состояния – еще не до конца протестирован, но работает и соответствует спецификации – мы стали устраивать собрания с командой WPF. Разработчики WPF были предполагаемыми основными потребителями свойств расширения. В WPF уже есть механизм, похожий на свойства расширения; было бы неплохо унифицировать этот механизм с нашим. К сожалению, рассмотрев хорошенько их реальные сценарии, мы прили к разочаровывающему выводу о том, что мы спроектировали не то; эта возможность на самом деле не решала их проблемы. Это, надо признать, провал процесса проектирования. Мы должны были поинтересоваться мнением основного потребителя намного раньше. Сделай мы это – и они могли бы либо повлиять на дизайн и получить что-то, пригодное для них, или бы мы выбросили эту возможность из плана без затрат на написание спецификации, кода, и планов тестирования.

Но, когда оказываешься в неприятной ситуации, приходится принимать решение прекратить выбрасывать хорошие деньги на плохое. Вместо того, чтобы нести дополнительные расходы – на тестирование, документацию, поставку потребителям, а потом поддержку этой возможности до конца дней языка – в обмен на возможность, которая не удовлетворяет потребностей наших потребителей, мы выбросили эту возможность. К тому моменту мы не были уверены, что у нас осталось достаточно времени на перепроектирование возможности правильным образом.

Так что, к сожалению, никаких свойств расширения в C# 4. Возможно, в гипотетической будущей версии C#.

Вот любопытный фрагмент кода:

object obj = "Int32";
string str1 = "Int32";
string str2 = typeof(int).Name;
Console.WriteLine(obj == str1); // true
Console.WriteLine(str1 == str2); // true
Console.WriteLine(obj == str2); // false !?

Конечно, если A равно B, и B равно C, то A равно C, это транзитивное своейство равенства. Похоже, что оно тут полностью нарушено.

Ну, прежде всего, хотя транзитивность и желательна, это всего лишь одна из многих ситуаций, в которых равенство в C# нетранзитивно. Вы не должны полагаться на транзитивность в общем случае, хотя, конечно же, есть множество частных случаев, где она справедлива. В качестве упражнения, вы могли бы посмотреть, сколько других нетранзитивностей сможете вспомнить. (Случайно, один из вопросов, который мне задали на собеседовании при приёме в эту команду был про разработку производительного алгоритма для определения нетранзитивностей в упрощённой версии алгоритма «наилучшего метода».)

Во-вторых, здесь происходит смешение двух разных видов равенства, которые случайно используют одинаковый синтаксис операторов. Мы смешиваем равенство по ссылке с равенством по значению. Объекты сравнивают по ссылке; в первом и третьем сравнении мы проверяем, что обе ссылыки указывают в точности на один и тот же объект. Во втором сравнении мы проверяем, одинаково ли содержимое двух строк, вне зависимости от того, представлены ли они одним объектом. Фактически, компилятор предупреждает вас о такой ситуации; такой код должен порождать предупреждение «возможно непреднамеренное сравнение ссылок».

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

Это объясняет, почему второе сравнение истинно – это сравнение значений – и почему третье сравнение ложно – это сравнение ссылок. Но это не объясняет, почему первое и третье сравнения противоречат друг другу.

Это результат маленькой оптимизации. Если у вас есть два идентичных строковых литерала в одной единице компиляции, то код, который мы генерируем, гарантирует, что только один объект строки создаётся CLR для всех экземпляров этого литерала в пределах сборки. Эта оптимизация называется «интернированием строк».

String.Empty – не константа, это поле только-для-чтения в другой сборке. Поэтому оно не интернируется с пустой строкой в вашей сборке; это два разных объекта.

Это объясняет, почему первое сравнение истинно: эти два литерала фактически превращаются в один и тот же объект строки. И это объясняет, почему третье сравнение ложно: литерал и вычисленное значение превращаются в разные объекты.

Зная это, вы теперь можете сделать обоснованное предположение причины, по которой мы имеем это противоестественное поведение:

object obj = "";
string str1 = "";
string str2 = String.Empty;
Console.WriteLine(obj == str1); // true
Console.WriteLine(str1 == str2); // true
Console.WriteLine(obj == str2); // иногда true, иногда false?!

Некоторые версии .NET автоматически интернируют пустую строку, некоторые – нет!

Но почему, можете вы спросить, мы не выполняем эту оптимизацию во время выполнения для каждой строки? Почему бы нам не превращать агрессивно все равные по значеням строки в равные по ссылкам? Конечно же расточительно иметь две одинаковые строки, когда можно занять вдвое меньше памяти.

Ответ – в том, что принцип ЛДНБ применим здесь в полной мере. То есть, Ланчей Даром Не Бывает. Интернирование имеет два положительных эффекта: оно уменьшает потребление памяти и уменьшает время сравнения двух строк. (Потому, что если все строки интернируются во время выполнения, то все сравнения строк могут быть дешёвыми сравнениями ссылок.) Но у этих положительных эффектов есть цена: выделение новой строки теперь требует от вас поиска по всем строкам в памяти для проверки, нет ли там уже такой. В нашей существующей оптимизации, цена невелика; во время компиляции нам известно, каковы строковые литералы в данной сборке и какие из них одинаковы. В предлагаемой оптимизации, эта цена платится во время выполнения, и может занимать весьма большую долю затрат времени на выделение строк.

Чтобы снизить затраты времени, вам бы пришлось построить хеш-таблицу всех строк в памяти. Это означает либо частое вычисление хеш-кодов, что само по себе затратно по времени, либо их хранение где-то. Если мы выбираем последнее, то внезапно мы увеличиваем нагрузку на память для строк, которые не дублируются. То есть, наша оптимизация заставляет обычный сценарий – подавляющее большинство пар строк не совпадают друг с другом – требовать больше памяти, чтобы редкий сценарий мог её сэкономить. Это выглядит плохой сделкой; обычно вы хотите оптимизировать для более вероятного случая.

Кроме того, у интернированных строк есть также и серьёзные проблемы с временем жизни. Когда их можно безопасно подвергнуть сборке мусора? Что, если новая копия строки создаётся в тот момент, когда старую удаляет сборщик в другом потоке? Самое безопасное – сделать интернированные строки бессмертными, что выглядит как утечка памяти. Утечки памяти плохо влияют на производительность, особенно когда ваша оптимизация – это попытка сэкономить память. ЛДНБ!

Короче, в общем случае не стоит интернировать все строки. Тем не менее, это может оказаться стоящим в некоторых особых случаях. Например, если бы вы писали на C# компилятор, то вы бы скорее всего порождали в процессе выполнения большое количество одинаковых строк. Наш компилятор C# написан на C++, где мы написали нашу собственную прослойку интернирования строк, чтобы мы могли выполнять дешёвые ссылочные сравнения для всех строк в вашей программе. Весьма вероятно, что «int» будет встречаться десятки, сотни, или тысячи раз в одной программе; глупо выделять одну и ту же строку снова и снова. Если вы пишете на C# компилятор, или какое-то другое приложение, в котором вы чувствуете, что стоит постараться не дать тысячам идентичных строк потребить много памяти, то вы можете заставить среду исполнения интернировать вашу строку при помощи метода String.Intern.

И, наоборот, если вы ненавидите интернирование слепой ненавистью, то можете заставить среду отключить всё интернирование строк в сборке при помощи атрибута CompilationRelaxation.

В любом случае, вернёмся к вопросу транзитивности: равенство ссылок на объекты на самом деле транзитивно. Оно также симметрично (A==B подразумевает B==A) и рефлексивно (A==A), так что это отношение эквивалентности. Похожим образом, равенство значений строк транзитивно, симметрично и рефлексивно, поскольку оно использует прямолинейное сравнение «символ за символом». Но когда вы смешиваете их, то равенство перестаёт быть транзитивным. Это странно, но, надеюсь, теперь доступно для понимания.

Вот хороший вопрос со StackOverflow:

Если у вас есть метод, принимающий «X», то вы должны передавать выражение типа X или что-то, приводимое к X. Скажем, выражение производного от X типа. Но если у вас есть метод, принимающий «ref X», то вы обязаны передавать ссылку на переменную типа X, точка. Почему это? Почему бы не разрешить типу варьироваться, как мы делаем для не-ref вызовов?

Предположим, что у вас есть классы Животное, Млекопитающее, Рептилия, Жираф, Черепаха и Тигр, с очевидными отношениями наследования.

Теперь предположим, что у вас есть метод void M(ref Млекопитающее m). M может как читать, так и писать m. Можно ли передать в M переменную типа Животное? Нет. Это было бы небезопасно. Такая переменная может ссылаться на Черепаху, но M предполагает, что там могут быть только Млекопитающие. Черепаха – не млекопитающее.

Вывод 1: Ref-параметры нельзя делать «больше». (Животных больше, чем млекопитающих, так что переменная становится «больше» потому, что в неё входит больше разных существ)

Можно ли передать в M переменную типа Жираф? Нет. M может записывать в m, и может захотеть записать туда экземпляр Тигра. Теперь вы засунули Тигра в переменную, которая имеет тип Жираф.

Вывод 2: Ref-параметры нельзя делать «меньше».

Теперь рассмотрим N(out Млекопитающее n).

Можно ли передать в N переменную типа Жираф? Нет. Как и в нашем предыдущем примере, N может записывать в n, и N может захотеть записать туда Тигра.

Вывод 3: Out-параметры нельзя делать «меньше».

Можно ли передать в N переменную типа Животное?

Хмм.

Ну, почему бы и нет? N не может читать из n, он может туда только писать, верно? Вы записываете Тигра в переменную типа Животное и всё в порядке, так?

Нет. Правило не в том, что «N может только записывать в n». Правила, вкратце, таковы:

1) N обязан записать в n перед тем, как выполнить нормальный возврат (если N бросает исключение, то с него взятки гладки)

2) N обязан записать что-то в n перед тем, как что-то оттуда прочитать.

Это позволяет такую последовательность событий:

• Объявляем поле x типа Животное.
• Передаём x как out-параметр в N
• N пишет Тигра в n, который является псевдонимом для x.
• В другом потоке, кто-то записывает в x Черепаху.
• N пытается читать содержимое n, и обнаруживает Черепаху в том, что, по его мнению, является переменной типа Млекопитающее.

Этот сценарий – использование многопоточности для записи в переменную, у которой есть псевдоним, – ужасен и вам ни в коем случае не стоит его реализовывать, но он возможен.

UPDATE: Комментатор Павел Минаев верно подметил, что нет нужды в многопоточности для нанесения увечий. Мы можем заменить четвёртый шаг на

• N делает вызов метода, который прямо или косвенно заставляет некоторый код записать в x Черепаху.

Независимо от того, каким образом может измениться содержимое переменной, мы явно хотим сделать нарушение системы типов незаконным.

Вывод 4: Out-параметры нельзя делать «больше».

Есть и другой аргумент в пользу этого вывода: «out» и «ref» на самом деле за кулисами совершенно одинаковы. CLR поддерживает только «ref»; «out» - это всего лишь «ref», для которого компилятор навязывает несколько другие правила насчёт того, когда рассматриваемая переменная подвергается определяющему присваиванию. Вот почему запрещено делать перегрузки метода, которые отличаются только out/ref-ностью параметров; CLR неспособен их различить! Так что правила типобезопасности для out вынуждены быть такими же, как и для ref.

Окончательный вывод: Ни ref ни out параметры не позволяют варьировать типы аргументов в местах вызова. Иное бы нарушило верифицируемую безопасность типов.

Так же, как «fixed» и «into», «partial» используется в С# двумя похожими-но-разными способами.

Задача частичного класса в том, чтобы позволить вам разбивать объявление класса на несколько частей, обычно расположенных в различных файлах. Мотиватором этой возможности был машинно-генерируемый код, который пользователю нужно было расширять путём прямых добавлений. Когда вы рисуете форму в дизайнере форм, дизайнер генерирует для вас класс, представляющий эту форму. Вы можете затем далее изменять этот класс, добавляя в него новый код. Если вы можете редактировать код, сгенерированный машиной, то возникает масса проблем. Что, если он будет сгенерирован повторно? Что, если машина использует сам код для хранения информации о дизайне формы, и ваши правки сбивают с толку парсер машины? Гораздо лучше просто поместить машинно-генерируемую половину в отдельный файл, сгенерировать комментарий «не трогайте это», и разместить пользовательский код в другом месте.

Есть и другие применения частичных классов, не связанные с автоматически генерируемым кодом, но они относительно редки. Вот некоторые случаи, где я вижу применение частичных классов:

• Если класс действительно большой, и реализует пачку интерфейсов, то, иногда, реализация каждого интерфейса в отдельном файле имеет смысл. Хотя, чаще это признак плохого кода, присущий классу, который пытается делать слишком много всего; разделение этой штуки на несколько классов может оказаться лучше.
• Иногда приятно выносить вложенные классы в отдельные файлы; единственный приличный способ этого добиться – это сделать содержащий их класс частичным.
• И так далее

Частичные методы – немножко другая история. Как и частичные классы, частичные методы – про склеивание множества объявлений одного и того же метода для улучшения сценариев, связанных с машинной генерацией кода. Но, несмотря на то, что высокоуровневые задачи этой возможности те же, детали весьма отличаются.

Способ, которым работают частичные методы – это наличие двух объявлений, «латентного», и «актуального». У латентного объявления нет тела, как будто это абстрактный метод. У актуального – есть. Латентное объявление располагается на машинно-сгенерированной стороне частичного класса, актуальное объявление попадает в часть, написанную человеком. Если у нас есть актуальное объявление, то латентное полностью игнорируется. Но если актуального объявления нет, то все вызовы метода устраняются, как будто он был скомпилирован с условным атрибутом! И, фактически, латентное объявление также устраняется в момент порождения метаданных для сгенерированного класса; как будто его и не было.

Причина для такого поведения – в том, что мы хотели сделать возможным такой сценарий:

// Машинно-генерируемый код:
partial class MyFoo
{
void ButtonClickEventHandler(/*всякое*/)
{
// вызвать пользовательский код чтобы посмотреть, не хочет ли он чего-нибудь сделать
OnBeforeButtonClick(всякое);
тра ля ля
// опять вызвать пользовательский код
OnAfterButtonClick(всякое);
}
partial void OnBeforeButtonClick(/*всякое*/);
partial void OnAfterButtonClick(/*всякое*/);
...

Пользователь будет модифицировать частичный класс; вставляя частичные методы, машинно-сгенерированная часть может повсеместно создать простые точки расширения, которые пользователь потом сможет реализовать. Но подумайте о негативных последствиях этого в мире без частичных методов. Пользователя заставляют реализовывать пустые методы. Если он этого не сделает, то получит ошибку. Потенциально там нужно реализовать сотни этих пустых методов, а это бесит. И каждый из этих методов генерирует нетривиальное количество метаданных, делая результирующую библиотеку больше, чем нужно. Дисковое пространство дёшево, но латентность сети заменила дисковое пространство в качестве фактора против больших сборок. Было бы здорово, если бы мы могли избавиться от этого груза метаданных.

Частичные методы удовлетворяют требованиям. Пользователь может предоставлять реализации для методов по собственному выбору, и это становится моделью с «платой за фактическое использование»; вы получаете столько расходов на реализацию, сколько методов вы реализуете.

Эта возможность во время процесса проектирования называлась «латентные и актуальные методы»; мы серьёзно рассматривали добавление новых ключевых слов «latent» и «actual». Но, поскольку эта возможность имеет смысл только в сценариях с частичными классами, то мы решили повторно использовать существующее контекстное ключевое слово «partial» и переименовали возможность. Надеюсь, что созвучие между двумя применениями «partial» помогает больше, чем тонкая разница вредит.

СУПЕР ЭКСТРА БОНУС: Ещё немного частичности

Мы рассматривали добавление третьего типа «частичности» в C# 4.0; эта возможность прошла через фазу проектирования, но была выброшена до реализации. (Если будет высокий спрос, то мы рассмотрим добавление её в гипотетических будущих версиях C#.)

Иногда вы участвуете в сценарии машинной генерации кода типа такого:

// сгенерировано машиной
partial class C
{
int blah;
...

И затем на той стороне, которую генерирует пользователь, вы хотите сделать что-то вроде:

// User generated
partial class C : ISerializable
{

И, о, чёрт, мне нужно пометить blah атрибутом NotSerialized, но я не могу редактировать текст blah потому, что когда его перегенерируют, это всё пропадёт.

Идея этого нового типа частичности – в том, чтобы повторять объявление члена – поля, метода, вложенного типа, чего угодно – с атрибутами метаданных. Это как латентные/актуальные методы, только наоборот; «актуальная» часть – на машинно-генерируемой стороне, а «латентная» часть на стороне, генерируемой пользователем, нужна только для добавления метаданных:

[NotSerialized] partial int blah; // на самом деле не объявляет поле

Мне нравится такая возможность, но во время процесса проектирования я сопротивлялся, как мог, использованию ключевого слова «partial» в третьем значении, слегка отличающемся от первых двух. Добавление такой путаницы один раз казалось оправданным, но дважды? Это перевешивает. Так что мы сошлись на добавлении другого контекстного ключевого слова:

[NotSerialized] existing int blah; // на самом деле не объявляет поле

Оформление объявления при помощи «existing» значило бы «это не настоящее объявление, это упоминание существующего объявления; пожалуйста, проверьте, что такое объявление существует где-то еще в этом частичном классе, и добавьте эти метаданные к тому члену».

Как я сказал, эта полезная возможность была выброшена из-за ограниченности ресурсов. Если у вас есть реально обалденные сценарии, которые бы она облегчила, то я был бы счастлив о них услышать; очевидно, я не могу делать никаких обещаний о будущих возможностях необъявленных, полностью гипотетических продуктов. Но реальные пользовательские сценарии являются сильным мотивирующим фактором в выделении бюджета для новых возможностей.