Non capisco gli argomenti contro il sovraccarico dell'operatore [chiuso]

Ho appena letto uno degli articoli di Joel in cui dice:

In generale, devo ammettere che ho un po 'paura delle caratteristiche del linguaggio che nascondono le cose . Quando vedi il codice

i = j * 5;

... in C sai, almeno, che j viene moltiplicato per cinque e i risultati memorizzati in i.

Ma se vedi lo stesso frammento di codice in C ++, non sai nulla. Niente. L'unico modo per sapere cosa sta realmente accadendo in C ++ è scoprire quali tipi io e j sono, qualcosa che potrebbe essere dichiarato da qualche altra parte. Questo perché j potrebbe essere di un tipo operator*sovraccarico e fa qualcosa di terribilmente spiritoso quando provi a moltiplicarlo.

(Enfasi mia.) Hai paura delle caratteristiche del linguaggio che nascondono le cose? Come puoi averne paura? Nascondere le cose (noto anche come astrazione ) non è una delle idee chiave della programmazione orientata agli oggetti? Ogni volta che chiami un metodo a.foo(b), non hai idea di cosa potrebbe fare. Devi scoprire quali tipi ae quali bsono, qualcosa che potrebbe essere dichiarato da qualche altra parte. Quindi dovremmo eliminare la programmazione orientata agli oggetti, perché nasconde troppe cose al programmatore?

E in che modo è j * 5diverso j.multiply(5), che potresti dover scrivere in una lingua che non supporta il sovraccarico dell'operatore? Ancora una volta, dovresti scoprire il tipo di je sbirciare all'interno del multiplymetodo, perché ecco, jpotrebbe essere di un tipo che ha un multiplymetodo che fa qualcosa di terribilmente spiritoso.

"Muahaha, sono un programmatore malvagio che nomina un metodo multiply, ma quello che fa in realtà è totalmente oscuro e non intuitivo e non ha assolutamente nulla a che fare con il moltiplicare le cose." È uno scenario che dobbiamo prendere in considerazione quando si progetta un linguaggio di programmazione? Quindi dobbiamo abbandonare gli identificatori dai linguaggi di programmazione perché potrebbero essere fuorvianti!

Se vuoi sapere cosa fa un metodo, puoi dare un'occhiata alla documentazione o sbirciare all'interno dell'implementazione. Il sovraccarico dell'operatore è solo zucchero sintattico e non vedo affatto come cambi il gioco.

Per favore, illuminami.

L'astrazione 'nasconde' il codice in modo da non doverti preoccupare dei meccanismi interni e spesso quindi non puoi cambiarli, ma l'intenzione non era di impedirti di guardarlo. Facciamo solo ipotesi sugli operatori e, come ha detto Joel, potrebbe essere ovunque. Avere una funzione di programmazione che richiede che tutti gli operatori sovraccarichi siano stabiliti in una posizione specifica può aiutare a trovarla, ma non sono sicuro che ne semplifichi l'utilizzo.

Non vedo fare * fare qualcosa che non assomigli molto alla moltiplicazione meglio di una funzione chiamata Get_Some_Data che cancella i dati.

IMHO, funzionalità linguistiche come il sovraccarico dell'operatore danno più potenza al programmatore. E, come tutti sappiamo, da un grande potere derivano grandi responsabilità. Le caratteristiche che ti danno più potenza ti danno anche più modi di spararti nel piede e, ovviamente, dovrebbero essere usate con giudizio.

Ad esempio, ha perfettamente senso sovraccaricare +l' *operatore class Matrixo per o class Complex. Tutti sapranno immediatamente cosa significa. D'altra parte, per me il fatto che ciò +significhi concatenare le stringhe non è affatto ovvio, anche se Java lo fa come parte del linguaggio e STL lo fa per std::stringusare il sovraccarico dell'operatore.

Un altro buon esempio di quando il sovraccarico dell'operatore rende più chiaro il codice sono i puntatori intelligenti in C ++. Volete che i puntatori intelligenti si comportino il più possibile come puntatori regolari, quindi ha perfettamente senso sovraccaricare l'unario *e gli ->operatori.

In sostanza, il sovraccarico dell'operatore non è altro che un altro modo per nominare una funzione. E c'è una regola per le funzioni di denominazione: il nome deve essere descrittivo, rendendo immediatamente ovvio ciò che fa la funzione. La stessa regola esatta si applica al sovraccarico dell'operatore.

In Haskell "+", "-", "*", "/" etc sono solo funzioni (infix).

Dovresti nominare una funzione di infissione "più" come in "4 più 2"? Perché no, se l'aggiunta è ciò che fa la tua funzione. Dovresti nominare la tua funzione "più" "+"? Perchè no.

Penso che il problema con i cosiddetti "operatori" sia che somigliano per lo più a operazioni matematiche e non ci sono molti modi per interpretarle e quindi ci sono grandi aspettative su cosa faccia un tale metodo / funzione / operatore.

EDIT: chiarito il mio punto

Sulla base delle altre risposte che ho visto, posso solo concludere che la vera obiezione al sovraccarico dell'operatore è il desiderio di un codice immediatamente evidente.

Questo è tragico per due motivi:

1. Portato alla sua logica conclusione, il principio secondo cui il codice dovrebbe essere immediatamente ovvio vorrebbe che tutti noi ancora stessimo codificando in COBOL.
2. Non impari dal codice che è immediatamente ovvio. Impara dal codice che ha senso una volta che ti prendi del tempo per pensare a come funziona.

Sono abbastanza d'accordo.

Se scrivi multiply(j,5), jpotrebbe essere di tipo scalare o matrice, rendendo multiply()più o meno complesso, a seconda di cosa jsia. Tuttavia, se abbandoni del tutto il sovraccarico, allora la funzione dovrebbe essere denominata multiply_scalar()o multiply_matrix()che renderebbe ovvio ciò che sta accadendo sotto.

C'è un codice in cui molti di noi lo preferiscono in un modo e c'è un codice in cui la maggior parte di noi lo preferisce in un altro modo. Gran parte del codice, tuttavia, cade nella terra di mezzo tra questi due estremi. Quello che preferisci lì dipende dal tuo background e dalle tue preferenze personali.

Vedo due problemi con il sovraccarico dell'operatore.

1. Il sovraccarico modifica la semantica dell'operatore, anche se ciò non è previsto dal programmatore. Ad esempio, quando si sovraccarico &&, ||o ,, si perdono i punti di sequenza che sono implicite le varianti integrate di questi operatori (così come il comportamento corto circuito degli operatori logici). Per questo motivo, è meglio non sovraccaricare questi operatori, anche se la lingua lo consente.
2. Alcune persone vedono l'operatore sovraccarico come una caratteristica così piacevole, iniziano a usarlo ovunque, anche se non è la soluzione appropriata. Questo fa sì che altre persone reagiscano in modo eccessivo nell'altra direzione e mettano in guardia contro il sovraccarico dell'operatore. Non sono d'accordo con nessuno dei due gruppi, ma prendo la via di mezzo: il sovraccarico dell'operatore dovrebbe essere usato con parsimonia e solo quando
   • l'operatore sovraccarico ha il significato naturale sia per gli esperti di dominio che per gli esperti di software. Se questi due gruppi non concordano sul significato naturale per l'operatore, non sovraccaricarlo.
   • per i tipi coinvolti, non esiste un significato naturale per l'operatore e il contesto immediato (preferibilmente la stessa espressione, ma non più di poche righe) chiarisce sempre qual è il significato dell'operatore. Un esempio di questa categoria sarebbe operator<<per i flussi.

Sulla base della mia esperienza personale, il modo Java di consentire più metodi, ma senza sovraccaricare l'operatore, significa che ogni volta che vedi un operatore sai esattamente cosa fa.

Non devi vedere se *invoca uno strano codice ma sai che è un moltiplicatore e si comporta esattamente come nel modo definito dalla specifica del linguaggio Java. Ciò significa che puoi concentrarti sul comportamento reale invece di scoprire tutte le cose di wicket definite dal programmatore.

In altre parole, proibire il sovraccarico dell'operatore è un vantaggio per il lettore , non per lo scrittore , e quindi facilita la manutenzione dei programmi!

Una differenza tra sovraccarico a * be chiamata multiply(a,b)è che quest'ultimo può essere facilmente superato. Se la multiplyfunzione non è sovraccaricata per tipi diversi, puoi scoprire esattamente cosa farà la funzione, senza dover tracciare i tipi di ae b.

Linus Torvalds ha un'interessante discussione sul sovraccarico dell'operatore. In qualcosa come lo sviluppo del kernel Linux, in cui la maggior parte delle modifiche vengono inviate tramite patch via e-mail, è importante che i manutentori possano capire cosa farà una patch con solo poche righe di contesto intorno a ogni modifica. Se le funzioni e gli operatori non sono sovraccarichi, la patch può essere più facilmente letta in modo indipendente dal contesto, poiché non è necessario passare attraverso il file modificato per capire quali sono tutti i tipi e verificare la presenza di operatori sovraccarichi.

Ho il sospetto che abbia qualcosa a che fare con la rottura delle aspettative. Sono abituato al C ++, sei abituato al comportamento dell'operatore che non è dettato interamente dalla lingua e non sarai sorpreso quando un operatore fa qualcosa di strano. Se sei abituato a linguaggi che non dispongono di tale funzionalità e poi vedi il codice C ++, porti con te le aspettative di quelle altre lingue e potresti essere brutalmente sorpreso quando scopri che un operatore sovraccarico fa qualcosa di strano.

Personalmente penso che ci sia una differenza. Quando è possibile modificare il comportamento della sintassi incorporata del linguaggio, diventa più opaco da ragionare. I linguaggi che non consentono la meta-programmazione sono sintatticamente meno potenti, ma concettualmente più semplici da comprendere.

Penso che sovraccaricare gli operatori matematici non sia il vero problema con il sovraccarico degli operatori in C ++. Penso che gli operatori di sovraccarico che non dovrebbero fare affidamento sul contesto dell'espressione (cioè il tipo) siano "cattivi". Ad esempio sovraccarico , [ ] ( ) -> ->* new deleteo anche unario *. Hai un certo insieme di aspettative da quegli operatori che non dovrebbero mai cambiare.

Capisco perfettamente che non ti piace l'argomento di Joel sul nascondersi. Neanche io. È davvero molto meglio usare '+' per cose come tipi numerici incorporati o per i tuoi come, per esempio, matrice. Ammetto che è pulito ed elegante per essere in grado di moltiplicare due matrici con '*' invece di '.multiply ()'. E dopo tutto abbiamo lo stesso tipo di astrazione in entrambi i casi.

Ciò che fa male qui è la leggibilità del tuo codice. In casi reali, non nell'esempio accademico di moltiplicazione di matrici. Soprattutto se la tua lingua consente di definire operatori che non sono inizialmente presenti nel nucleo della lingua, ad esempio =:=. A questo punto sorgono molte altre domande. Di cosa si tratta quel maledetto operatore? Voglio dire qual è la precedenza di quella cosa? Qual è l'associatività? In quale ordine viene a =:= b =:= crealmente eseguito?

Questo è già un argomento contro il sovraccarico dell'operatore. Non sei ancora convinto? Il controllo delle regole di precedenza non ti ha richiesto più di 10 secondi? Ok, andiamo oltre.

Se inizi a utilizzare un linguaggio che consente il sovraccarico degli operatori, ad esempio quello popolare il cui nome inizia con 'S', imparerai rapidamente che i progettisti di biblioteche adorano ignorare gli operatori. Naturalmente sono ben istruiti, seguono le migliori pratiche (non c'è cinismo qui) e tutte le loro API hanno perfettamente senso quando le guardiamo separatamente.

Ora immagina di dover usare alcune API che fanno un uso pesante degli operatori che sovraccaricano insieme in un unico pezzo di codice. O ancora meglio: devi leggere un codice legacy del genere. Questo è quando il sovraccarico dell'operatore fa davvero schifo. Fondamentalmente se ci sono molti operatori sovraccarichi in un posto, inizieranno presto a mescolarsi con gli altri caratteri non alfanumerici nel codice del programma. Si mescoleranno con caratteri non alfanumerici che non sono realmente operatori ma piuttosto alcuni elementi grammaticali del linguaggio più fondamentali che definiscono cose come blocchi e ambiti, modellano le dichiarazioni di controllo del flusso o denotano alcune meta-cose. Dovrai mettere gli occhiali e avvicinare gli occhi di 10 cm al display LCD per capire quel disordine visivo.

In generale, evito di utilizzare il sovraccarico dell'operatore in modi non intuitivi. Cioè, se ho una classe numerica, il sovraccarico * è accettabile (e incoraggiato). Tuttavia, se ho un dipendente di classe, cosa farebbe l'overloading *? In altre parole, sovraccaricare gli operatori in modi intuitivi che facilitano la lettura e la comprensione.

Accettabile / Incoraggiato:

class Complex
{
public:
    double r;
    double i;

    Complex operator*(const Compex& rhs)
    {
        Complex result;
        result.r = (r * rhs.r) - (i * rhs.i);
        result.i = (r * rhs.i) + (i * rhs.r);
        return result;
    }
};

Non accettabile:

class Employee
{
public:
    std::string name;
    std::string address;
    std::string phone_number;

    Employee operator* (const Employee& e)
    {
        // what the hell do I do here??
    }
};

Oltre a quanto è già stato detto qui, c'è un altro argomento contro il sovraccarico dell'operatore. In effetti, se scrivi +, è abbastanza ovvio che intendi aggiungere qualcosa a qualcosa. Ma non è sempre così.

Lo stesso C ++ fornisce un ottimo esempio di questo caso. Come stream << 1dovrebbe essere letto? flusso spostato a sinistra di 1? Non è affatto ovvio a meno che tu non sappia esplicitamente che << in C ++ scrive anche nello stream. Tuttavia, se questa operazione fosse implementata come metodo, nessuno sviluppatore sano scriverà o.leftShift(1), sarebbe qualcosa di simile o.write(1).

La linea di fondo è che rendendo non disponibile il sovraccarico dell'operatore, il linguaggio fa riflettere i programmatori sui nomi delle operazioni. Anche se il nome scelto non è perfetto, è ancora più difficile interpretare erroneamente un nome piuttosto che un segno.

Rispetto ai metodi esplicitati, gli operatori sono più brevi, ma non richiedono parentesi. Le parentesi sono relativamente scomode da digitare. E devi bilanciarli. In totale, qualsiasi chiamata di metodo richiede tre caratteri di semplice rumore rispetto a un operatore. Questo rende l'utilizzo degli operatori molto, molto allettante.
Perché altrimenti qualcuno vorrebbe questo cout << "Hello world":?

Il problema con il sovraccarico è che la maggior parte dei programmatori è incredibilmente pigra e la maggior parte dei programmatori non può permettersi di esserlo.

Ciò che spinge i programmatori C ++ all'abuso del sovraccarico dell'operatore non è la sua presenza, ma l'assenza di un modo più ordinato di eseguire chiamate di metodo. E le persone non hanno solo paura del sovraccarico dell'operatore perché è possibile, ma perché è fatto.
Si noti che ad esempio in Ruby e Scala nessuno ha paura del sovraccarico dell'operatore. A parte il fatto che l'uso degli operatori non è in realtà più breve dei metodi, un'altra ragione è che Ruby limita il sovraccarico degli operatori a un minimo ragionevole, mentre Scala consente di dichiarare i propri operatori rendendo così banale evitare collisioni.

Il motivo per cui l'overloading dell'operatore è spaventoso, è perché esiste un gran numero di programmatori che non PENSAREbbero mai, il che *non significa semplicemente "moltiplicare", mentre un metodo come foo.multiply(bar)almeno indica immediatamente a quel programmatore che qualcuno ha scritto un metodo di moltiplicazione personalizzato . A quel punto si domandano perché e vanno a indagare.

Ho lavorato con "buoni programmatori" che si trovavano in posizioni di alto livello che avrebbero creato metodi chiamati "CompareValues" che avrebbero preso 2 argomenti e applicato i valori uno dall'altro e restituito un valore booleano. O un metodo chiamato "LoadTheValues" che andrebbe nel database per altri 3 oggetti, ottenendo valori, eseguendo calcoli, modificandolo thise salvandolo nel database.

Se sto lavorando in team con quei tipi di programmatori, so immediatamente di indagare su ciò su cui hanno lavorato. Se hanno sovraccaricato un operatore, non ho assolutamente modo di sapere che lo hanno fatto se non per presumere che lo facessero e andare a cercare.

In un mondo perfetto, o in una squadra con programmatori perfetti, il sovraccarico dell'operatore è probabilmente uno strumento fantastico. Devo ancora lavorare su un team di programmatori perfetti, quindi è per questo che fa paura.