ref locals и ref returns в C#: подводные камни производительности

[kekekeks]

воспользоваться изменяемым (mutable) типом значения:

Уважаемые представители Microsoft. Вы когда технические статьи сюда кидаете по .NET, найдите переводчика, который хоть немного знаком с платформой и не будет переводить "value type" как "тип значения". И таких "ляпов" по тексту десятки. Единственный способ понять о чём речь — перевести обратно на английский.

Выглядит как полное пренебрежение к аудитории, которая будет это читать.

[Lofer]

Зачем эти навороты в зоопарке? Все возращается к тому, с чего начинали: указатели это плохо, потому что сложно контролировтаь время жизни объектов и могут быть утечки памяти, а программисту сложно будет, да и сборщик мусора простой и быстрый. Сейчас вам не надо об этом думать — .Net нет все сделает сам.
Прошло 18 лет — и те же вопросы и механизмы из С++ тянут в .Net. Лучше бы множественное наследование вернули :)

[dimka11]

default interface implementation в разработке.

[mayorovp]

Все эти ref — это управляемые указатели, про которые сборщик мусора знает.

Тут наоборот тенденция, появляются способы делать безопасно то, что раньше делалось только через unsafe.

[Exponent]

Против множественного наследования, потом проследить ничего нельзя.

[nsinreal]

Как мне кажется, большинство этих вещей программисту средней руки не особо пригодится. Зато эти вещи сделают код библиотек более быстрым и менее требовательным к ресурсам. Сплошная выгода.

[qw1]

ссылка только для чтения на структуру, доступную для записи, создает защитную копию «в точке вызова»

Это ли не ошибка проектирования спецификации языка?

Почему в c++ можно присвоить const-ссылку на переменную, доступную для записи или скопировать указатель на const-значение из указателя на изменяемое значение?

Может, есть какие-то подводные камни, но я их не вижу сходу.

[qw1]

Хотя, возможно, под кейвордом readonly создатели C# понимали не запрет записи, а гарантию, что повторное чтение всегда даст тот же результат, тогда логично.

Тогда, в отличие от c++, нельзя на одну структуру сделать две ссылки — одну обычную, а вторую readonly. Для второй всегда будет создана копия структуры.

[Lofer]

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

[mayorovp]

Нет, копия создается в другом месте.

ref readonly foo = ...;
foo.Bar(); // вот тут создается копия, потому что метод Bar может изменить содержимое foo

[qw1]

Есть ли возможность у функции Bar указать, что она может вызываться на readonly-ссылке?

[AnarchyMob]

Есть ли возможность у функции Bar указать, что она может вызываться на readonly-ссылке?

Такой возможности нет, лучше просто пометить структуру как readonly и не заморачиваться, смело передавать структуру в метод через in и возвращать в ref readonly

Struct и readonly: как избежать падения производительности