Dlaczego nie jest możliwe przeciążenie operatora przypisania złożonego w C #?

11

Tytuł wprowadza w błąd, więc proszę przeczytać całe pytanie :-) .

Przez „operator przypisania złożonego” mam na myśli taką konstrukcję op=, na przykład +=. Czysty operator przypisania ( =) nie należy do mojego pytania.

Przez „dlaczego” nie mam na myśli opinii, ale zasób (książkę, artykuł itp.), Gdy niektórzy projektanci lub ich współpracownicy itp. Wyrażają swoje rozumowanie (tj. Źródło wyboru projektu).

Zastanawia mnie asymetria występująca w C ++ i C # ( tak, wiem, że C # to nie C ++ 2.0 ) - w C ++ przeciążymy operatora, +=a następnie prawie automatycznie napiszemy odpowiedni +operator w oparciu o wcześniej zdefiniowany operator. W języku C # jest odwrotnie - przeciążasz się +i +=jest dla Ciebie syntetyzowany.

Jeśli się nie mylę, późniejsze podejście zabija szansę na optymalizację w przypadku faktycznej +=, ponieważ trzeba stworzyć nowy obiekt. Tak więc musi być duża zaleta takiego podejścia, ale MSDN jest zbyt nieśmiały, aby o tym powiedzieć.

I zastanawiam się, co to za korzyść - więc jeśli zauważyłeś wyjaśnienie w jakiejś książce C #, wideo na temat technologii, wpisie na blogu, będę wdzięczny za odniesienie.

Najbliższą rzeczą, jaką znalazłem, jest komentarz na blogu Erica Lipperta. Dlaczego przeciążeni operatorzy są zawsze statyczni w C #? autor: Tom Brown. Jeśli najpierw zdecydowano o przeciążeniu statycznym, po prostu określa, którzy operatorzy mogą być przeciążeni dla struktur. To dodatkowo decyduje o tym, co może być przeciążone dla klas.

c# language-design operators Greenoldman
źródło
3
Czy masz link do nowego stylu C ++? Naiwnie przeciążanie +=wydaje się absurdalne; dlaczego miałbyś przeciążać operację złożoną zamiast jej części?
Telastyn
1
Wierzę, że terminem tym są „operatorzy przypisania złożonego”.
Ixrec
2
@greenoldman Telastyn prawdopodobnie sugerował, że implementacja + = w kategoriach + wydaje się bardziej naturalna niż na odwrót, ponieważ semantycznie + = jest kompozycją + i =. Zgodnie z moją najlepszą wiedzą , posiadanie + call + = jest w dużej mierze sztuczką optymalizacyjną.
Ixrec
1
@Ixrec: Czasami a + = b ma sens, podczas gdy a = a + b nie: Weź pod uwagę, że tożsamość może być ważna, A nie może być duplikowane, cokolwiek. Czasami a = a + b ma sens, podczas gdy a + = b nie: Rozważ niezmienne łańcuchy. Tak naprawdę potrzebna jest umiejętność samodzielnego decydowania, które z nich będzie przeciążone. Oczywiście automatyczne generowanie brakującego, jeśli istnieją wszystkie niezbędne elementy składowe i nie jest to wyraźnie wyłączone, jest dobrym pomysłem. Nie, że C # pozwala na ten bankomat, afaik.
Deduplicator
4
@greenoldman - Rozumiem tę motywację, ale osobiście uważam, że *=mutacja typu odniesienia jest semantycznie niepoprawna.
Telastyn

Odpowiedzi:

12

Nie mogę znaleźć odniesienia do tego, ale zrozumiałem, że zespół C # chciał zapewnić rozsądny podzbiór przeciążania operatora. W tym czasie przeciążenie operatora miało zły rap. Ludzie twierdzili, że zaciemnia kod i można go używać tylko do zła. Zanim projektowano C #, Java pokazała nam, że żadne przeciążenie operatora nie jest denerwujące.

Więc C # chciał zrównoważyć przeciążenie operatora, aby trudniej było robić zło, ale można było też robić fajne rzeczy. Zmiana semantyki przydziału była jedną z rzeczy, które zawsze uważano za złe. Pozwalając +=i jego krewni być przeciążona, pozwoliłoby to tego rodzaju rzeczy. Na przykład, jeśli +=zmutowane odniesienie zamiast nowego, nie będzie zgodne z oczekiwaną semantyką, co prowadzi do błędów.

Telastyn
źródło
Dziękuję, jeśli nie masz nic przeciwko, pozostanę dłużej otwarte na to pytanie, a jeśli nikt nie pobije Cię uzasadnieniem rzeczywistego projektu, zamknę je przyjmując twoje. Jeszcze raz Ci dziękuję.
greenoldman
@greenoldman - również powinieneś. Też mam nadzieję, że ktoś przyjdzie z odpowiedzią zawierającą bardziej konkretne odniesienia.
Telastyn
Czy to jest miejsce, w którym niemożność mówienia zarówno o wskaźniku, jak i pointie wygodnie i jednoznacznie pokazuje jego głowę? Cholerny wstyd.
Deduplicator
„Ludzie twierdzili, że to zaciemnił kod” - to wciąż prawda, czy widziałeś niektóre biblioteki F #? Hałas operatora. Np quanttec.com/fparsec
Den