Почему невозможно перегрузить составной оператор присваивания в C #?


11

Название вводит в заблуждение, поэтому, пожалуйста, прочитайте весь вопрос :-) .

Под «составного оператора присваивания» Я имею в виду конструкцию , как это op=, например +=. Оператор чистого присваивания ( =) не относится к моему вопросу.

Под «почему» я имею в виду не мнение, а ресурс (книгу, статью и т. Д.), Когда некоторые из дизайнеров или их коллеги и т. Д. Выражают свои соображения (т. Е. Источник выбора дизайна).

Я озадачен асимметрией, обнаруженной в C ++ и C # ( да, я знаю, что C # - это не C ++ 2.0 ) - в C ++ вы перегружаете оператор, +=а затем почти автоматически пишете соответствующий +оператор, полагаясь на ранее определенный оператор. В C # все наоборот - вы перегружены +и +=синтезированы для вас.

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

И мне интересно, что это за преимущество - так что, если вы заметили объяснение в какой-то книге на C #, видео о технических выступлениях, записи в блоге, я буду благодарен за ссылку.

Самое близкое, что я нашел, - это комментарий в блоге Эрика Липперта. Почему перегруженные операторы всегда статичны в C #? Том Браун Если сначала была решена статическая перегрузка, она просто указывает, какие операторы могут быть перегружены для структур. Это далее диктует, что может быть перегружено для классов.


3
У вас есть ссылка на новый стиль C ++? Наивно, перегрузка +=сначала кажется абсурдной; почему вы перегружаете комбинированную операцию, а не ее части?
Теластин

1
Я считаю, что термин для них "составные операторы присваивания".
Ixrec

2
@greenoldman Теластин, вероятно, подразумевал, что реализация + = в терминах + кажется более естественной, чем наоборот, так как семантически + = является композицией + и =. Насколько я знаю , наличие + call + = - это в значительной степени прием оптимизации.
Ixrec

1
@Ixrec: Иногда a + = b имеет смысл, в то время как a = a + b - нет: учтите, что идентификация может быть важной, A не может быть продублирована. Иногда a = a + b имеет смысл, а a + = b - нет. Рассмотрим неизменяемые строки. Таким образом, на самом деле нужна способность решать, какой из них перегружать отдельно. Конечно, хорошей идеей является автоматическая генерация недостающего, если все необходимые строительные блоки существуют и они явно не отключены. Не то, что C # позволяет это, афаик.
дедупликатор

4
@greenoldman - Я понимаю эту мотивацию, но лично я считаю, *=что изменение типа ссылки семантически неверно.
Теластин,

Ответы:


12

Я не могу найти ссылку на это, но, насколько я понимаю, команда C # хотела предоставить разумную часть перегрузки операторов. В то время перегрузка оператора имела плохой рэп. Люди утверждали, что он запутал код и мог быть использован только для зла. К тому времени , C # проектировался, Java показал нам , что нет перегрузки операторов не был вид раздражает.

Поэтому C # хотел уравновесить перегрузку операторов, чтобы было труднее творить зло, но вы также можете делать хорошие вещи. Изменение семантики присваивания было одной из тех вещей, которые всегда считались злыми. Позволяя +=и его родству быть перегруженным, это позволило бы такого рода вещи. Например, если +=изменить ссылку, а не создать новую, она не будет следовать ожидаемой семантике, что приведет к ошибкам.


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

@greenoldman - так и надо. Я тоже надеюсь, что кто-то придет с ответом с более конкретными ссылками.
Теластин

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

«Люди утверждали, что он запутал код» - правда, правда, вы видели некоторые библиотеки F #? Операторский шум. Например, Quanttec.com/fparsec
День
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.