Quali sono i problemi di portare C ++ - const in un linguaggio?

Sono interessato all'idea del C ++ - come constnon quella particolare esecuzione (come il casting away const).

Prendiamo ad esempio C # - manca C ++ - come const, e la ragione è la solita - persone e tempo. Qui inoltre sembra che il team di C # abbia esaminato l'esecuzione di C ++ di constmarketing CLR e ne abbia avuto abbastanza a questo punto (vedere perché non esiste un metodo membro const in c # e parametro const ; grazie Svick). Sia se ci muoviamo oltre, qualcos'altro?

C'è qualcosa di più profondo? Prendiamo ad esempio la multi-ereditarietà: di solito è vista come difficile da comprendere (per l'utente) e quindi non aggiunta al linguaggio (come il problema del diamante).

C'è qualcosa nella NATURA di constche pongono un problema che è meglio per il linguaggio per evitarlo? Qualcosa come decidere se constdovrebbe essere profondo o superficiale (avere un constcontenitore significa che non posso aggiungere nuovo elemento o alterare anche elementi esistenti; cosa succede se gli elementi sono di tipo di riferimento)?

AGGIORNAMENTO : mentre menziono C #, e quindi facendo una prospettiva storica, sono interessato alla natura dei potenziali problemi della constlingua.

Questa non è una sfida delle lingue. Per favore ignora fattori come le tendenze attuali o la popolarità - Sono interessato solo a problemi tecnici - grazie.

Nota se questo è adatto a te, ma in linguaggi funzionali come Standard ML tutto è immutabile per impostazione predefinita. La mutazione è supportata attraverso un reftipo di erenza generico . Quindi una intvariabile è immutabile e una ref intvariabile è un contenitore mutabile per ints. Fondamentalmente, le variabili sono variabili reali in senso matematico (un valore sconosciuto ma fisso) e refs sono "variabili" in senso imperativo di programmazione - una cella di memoria che può essere scritta e da cui leggere. (Mi piace chiamarli assegnabili .)

Penso che il problema constsia duplice. Innanzitutto, il C ++ manca della garbage collection, necessaria per avere strutture di dati persistenti non banali . const deve essere profondo per avere un senso, ma avere valori completamente immutabili in C ++ è impraticabile.

In secondo luogo, in C ++ è necessario optare constpiuttosto che non. Ma quando ti dimentichi di constqualcosa e in seguito lo risolvi, finirai nella situazione di "avvelenamento da costanti" menzionata nella risposta di @ RobY in cui il constcambiamento si ripercuoterà su tutto il codice. Se constfosse l'impostazione predefinita, non ti ritroveresti ad applicare constretroattivamente. Inoltre, dover aggiungere constovunque aggiunge molto rumore al codice.

Sospetto che i linguaggi tradizionali che seguirono (ad es. Java) furono fortemente modellati dal successo e dal modo di pensare di C e C ++. Caso in questione, anche con la raccolta dei rifiuti, le API della maggior parte delle lingue assumono strutture di dati mutabili. Il fatto che tutto sia mutevole e l'immutabilità è visto come un caso esemplare che parla a lungo della mentalità imperativa dietro le lingue popolari.

EDIT : Dopo aver riflettuto sul commento di Greenoldman mi sono reso conto che constnon riguarda direttamente l'immutabilità dei dati; constcodifica nel tipo di metodo se ha effetti collaterali sull'istanza.

È possibile utilizzare la mutazione per ottenere un comportamento referenzialmente trasparente . Supponiamo di avere una funzione che, quando chiamata, restituisce in successione valori diversi, ad esempio una funzione che legge un singolo carattere da stdin. Potremmo usare cache / memoize i risultati di questa funzione per produrre un flusso di valori referenzialmente trasparente. Lo stream sarebbe un elenco collegato i cui nodi chiameranno la funzione la prima volta che si tenta di recuperare il loro valore, ma quindi memorizzare nella cache il risultato. Quindi, se il stdinproblema persiste Hello, world!, la prima volta che provi a recuperare il valore del primo nodo, ne leggerà uno chare tornerà H. Successivamente continuerà a tornare Hsenza ulteriori chiamate per leggere a char. Allo stesso modo, il secondo nodo avrebbe letto un chardastdinla prima volta che provi a recuperarne il valore, questa volta restituisce ee memorizza nella cache quel risultato.

La cosa interessante qui è che hai trasformato un processo intrinsecamente stato in un oggetto apparentemente senza stato. Tuttavia, è stato necessario mutare lo stato interno dell'oggetto (memorizzando nella cache i risultati) per raggiungere questo obiettivo: la mutazione era un effetto benigno . È impossibile rendere il nostro CharStream constanche se il flusso si comporta come un valore immutabile. Ora immagina che ci sia Streamun'interfaccia con i constmetodi e tutte le tue funzioni si aspettano const Streams. Il tuo CharStreamnon può implementare l'interfaccia!

( EDIT 2: Apparentemente c'è una parola chiave C ++ chiamata mutableche ci permetterebbe di imbrogliare e creareCharStream const . Tuttavia, questa scappatoia distrugge constle garanzie - ora non puoi davvero essere sicuro che qualcosa non muterà attraverso i suoi constmetodi. Suppongo che non sia così male dal momento che è necessario richiedere esplicitamente la scappatoia, ma si fa ancora completamente affidamento sul sistema d'onore.)

In secondo luogo, supponiamo di avere funzioni di ordine elevato, ovvero è possibile passare funzioni come argomenti ad altre funzioni. constness fa parte della firma di una funzione, quindi non si sarebbe in grado di passare le non constfunzioni come argomenti alle funzioni che si aspettano constfunzioni. Applicare ciecamente constqui porterebbe a una perdita di generalità.

Infine, manipolare un constoggetto non garantisce che non stia mutando uno stato esterno (statico o globale) alle tue spalle, quindi constle garanzie non sono così forti come sembrano inizialmente.

Non mi è chiaro che codificare la presenza o l'assenza di effetti collaterali nel sistema dei tipi sia universalmente una buona cosa.

Il problema principale è che i programmatori tendono a non usarlo abbastanza, quindi quando colpiscono un posto dove è richiesto, o un manutentore in seguito vuole correggere la correttezza const, c'è un enorme effetto a catena. Puoi ancora scrivere un codice immutabile perfettamente buono senza const, il tuo compilatore non lo imporrà e avrà un momento più difficile da ottimizzare. Alcune persone preferiscono che il loro compilatore non li aiuti. Non capisco quelle persone, ma ce ne sono molte.

Nei linguaggi funzionali, praticamente tutto è const, ed essere mutevole è la rara eccezione, se è permesso a tutti. Ciò ha diversi vantaggi, come una più facile concorrenza e un ragionamento più semplice sullo stato condiviso, ma ci vuole un po 'per abituarsi se si proviene da una lingua con una cultura mutevole. In altre parole, non volere constè un problema di persone, non tecnico.

Vedo gli svantaggi come:

• "avvelenamento da const" è un problema quando una dichiarazione di const può forzare una dichiarazione precedente o successiva a utilizzare const, e ciò può far sì che la sua precedente delle seguenti dichiarazioni utilizzi const, ecc. E se l'avvelenamento da const scorre in una classe in una libreria di cui non hai il controllo, quindi puoi rimanere bloccato in un brutto posto.

• non è una garanzia assoluta. Di solito ci sono casi in cui la const protegge solo il riferimento, ma non è in grado di proteggere i valori sottostanti per un motivo o per l'altro. Anche in C, ci sono casi limite che const non può raggiungere, il che indebolisce la promessa che const fornisce.

• in generale, il sentimento del settore sembra allontanarsi da forti garanzie in fase di compilazione, per quanto confort possano portarti e io. Quindi per il pomeriggio spendo toccando il 66% della mia base di codice a causa di avvelenamento da costanti, alcuni Python guy ha eliminato 10 moduli Python perfettamente funzionanti, ben progettati, testati e perfettamente funzionanti. E non stava nemmeno hackerando quando lo ha fatto.

Quindi forse la domanda è: perché portare avanti una caratteristica potenzialmente controversa di cui anche alcuni esperti sono ambivalenti quando stai cercando di ottenere l'adozione del tuo nuovo linguaggio spettrale?

EDIT: risposta breve, una nuova lingua ha una ripida collina da scalare per l'adozione. I progettisti devono davvero riflettere attentamente su quali funzionalità sono necessarie per ottenere l'adozione. Prendi Go, per esempio. Google ha troncato brutalmente alcune delle più profonde battaglie religiose facendo alcune scelte di design in stile Conan-il-Barbaro, e in realtà penso che il linguaggio sia migliore, da quello che ho visto.

Ci sono alcuni problemi filosofici nell'aggiungere consta una lingua. Se si dichiara consta una classe, ciò significa che la classe non può cambiare. Ma una classe è un insieme di variabili accoppiate a metodi (o mutatori). Raggiungiamo l'astrazione nascondendo lo stato di una classe dietro una serie di metodi. Se una classe è progettata per nascondere lo stato, allora hai bisogno di mutatori per cambiare quello stato dall'esterno e non lo è constpiù. Quindi è possibile dichiarare solo constalle classi che sono immutabili. Quindi constsembra possibile solo in scenari in cui le classi (oi tipi che vuoi dichiarare const) sono banali ...

Quindi abbiamo bisogno constcomunque? Non la penso così. Penso che puoi facilmente farne a meno constse hai un buon design. Di quali dati hai bisogno e dove, quali metodi sono dati da dati a dati e quali astrazioni ti servono per I / O, rete, vista ecc. Quindi dividi naturalmente moduli e classi che si occupano dello stato e hai metodi e classi immutabili che non necessitano di stato.

Penso che la maggior parte dei problemi sorga con oggetti dati di grandi dimensioni che possono salvare, trasformare e disegnare se stessi e quindi si desidera passare ad un renderer per esempio. Quindi non è possibile copiare il contenuto dei dati, perché è troppo costoso per un grande oggetto-dati. Ma non vuoi neanche che cambi, quindi hai bisogno di qualcosa come constpensi. Lascia che il compilatore capisca i tuoi difetti di progettazione. Tuttavia, se si suddividono tali oggetti solo in un oggetto dati immutabile e si implementano i metodi nel modulo responsabile, è possibile passare (solo) il puntatore e fare le cose che si desidera fare con i dati garantendo allo stesso tempo l'immutabilità.

So che in C ++ è possibile dichiarare alcuni metodi conste non dichiararli su altri metodi, perché sono mutatori. E poi qualche tempo dopo hai bisogno di una cache e quindi un getter muta un oggetto (perché si carica lentamente) e non lo è constpiù. Ma quello era il punto centrale di questa astrazione, giusto? Non sai quale stato viene mutato ad ogni chiamata.