Perché non è possibile sovraccaricare l'operatore di assegnazione composto in C #?


11

Il titolo è fuorviante, quindi per favore leggi l'intera domanda :-) .

Per "operatore di assegnazione composto" ho in mente un costrutto come questo op=, per esempio +=. L'operatore di assegnazione puro ( =) non appartiene alla mia domanda.

Per "perché" non intendo un'opinione, ma una risorsa (libro, articolo, ecc.) Quando alcuni designer, i loro colleghi, ecc. Esprimono il loro ragionamento (cioè la fonte della scelta del design).

Sono sconcertato dall'asimmetria trovata in C ++ e C # ( sì, so che C # non è C ++ 2.0 ) - in C ++ sovraccaricheresti l'operatore +=e poi scriveresti quasi automaticamente un +operatore appropriato basandoti su un operatore precedentemente definito. In C # è al contrario - sovraccarichi +ed +=è sintetizzato per te.

Se non sbaglio l'approccio successivo uccide una possibilità di ottimizzazione in caso di effettiva +=, poiché è necessario creare un nuovo oggetto. Quindi ci deve essere un grande vantaggio di tale approccio, ma MSDN è troppo timido per dirlo.

E mi chiedo quale sia il vantaggio - quindi se hai notato spiegazioni in alcuni libri di C #, video di talk-tech, post di blog, ti sarei grato per il riferimento.

La cosa più vicina che ho trovato è un commento sul blog di Eric Lippert Perché gli operatori sovraccarichi sono sempre statici in C #? di Tom Brown. Se il sovraccarico statico è stato deciso per primo, indica semplicemente quali operatori possono essere sovraccaricati per le strutture. Ciò determina ulteriormente ciò che può essere sovraccaricato per le classi.


3
Hai un link per il nuovo stile C ++? Ingenuamente, il sovraccarico +=sembra prima assurdo; perché dovresti sovraccaricare un'operazione combinata anziché le sue parti?
Telastyn,

1
Credo che il termine per questi sia "operatori di assegnazione composti".
Ixrec,

2
@greenoldman Telastyn stava probabilmente insinuando che l'implementazione di + = in termini di + sembra più naturale del contrario, poiché semanticamente + = è una composizione di + e =. Per quanto ne so , avere + call + = è in gran parte un trucco di ottimizzazione.
Ixrec,

1
@Ixrec: A volte, a + = b ha senso, mentre a = a + b no: considera che l'identità potrebbe essere importante, una A non può essere duplicata, qualunque cosa. A volte, a = a + b ha un senso, mentre a + = b no: considera le stringhe immutabili. Quindi, uno ha effettivamente bisogno della capacità di decidere quale sovraccaricare separatamente. Naturalmente, generare automaticamente quello mancante, se esistono tutti i mattoni necessari e non è disabilitato esplicitamente, è una buona idea. Non che C # lo permetta, certo.
Deduplicatore,

4
@greenoldman - Capisco questa motivazione, ma personalmente troverei che *=mutare un tipo di riferimento fosse semanticamente errato.
Telastyn,

Risposte:


12

Non riesco a trovare il riferimento per questo, ma la mia comprensione era che il team C # voleva fornire un sottoinsieme sano di sovraccarico dell'operatore. A quel tempo, il sovraccarico dell'operatore ha avuto un brutto colpo. La gente ha affermato che offuscava il codice e poteva essere usata solo per il male. Al momento della progettazione di C #, Java ci aveva mostrato che nessun sovraccarico da parte dell'operatore era un po 'fastidioso.

Quindi C # voleva bilanciare il sovraccarico dell'operatore in modo che fosse più difficile fare del male, ma si potevano anche fare cose carine. Cambiare la semantica del compito era una di quelle cose che era considerata sempre malvagia. Consentendo +=il sovraccarico e la sua parentela, permetterebbe quel genere di cose. Ad esempio, se +=mutasse il riferimento anziché crearne uno nuovo, non seguirebbe la semantica prevista, portando a bug.


Grazie, se non ti dispiace, terrò questa domanda aperta più a lungo e se nessuno ti batterà con il ragionamento del progetto reale, la chiuderò accettando la tua. Ancora una volta grazie.
Greenoldman,

@greenoldman - anche tu dovresti. Anch'io spero che qualcuno abbia una risposta con riferimenti più concreti.
Telastyn,

Quindi, questo è un posto dove l'impossibilità di parlare sia del puntatore che della punta in modo confortevole e inequivocabilmente alleva la testa? Accidenti vergogna.
Deduplicatore,

"La gente ha affermato che ha offuscato il codice" - è comunque vero, hai visto alcune delle librerie F #? Rumore dell'operatore. Ad esempio quanttec.com/fparsec
Den,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.