Dopo 15 anni di C ++, non ho ancora imparato ad amare usando const. Capisco che sia utile, ma non sono mai stato in realtà in una situazione in cui const correct avrebbe evitato il problema I stava affrontando.
Quindi come sei arrivato ad amare i benefici di una fonte di culto?
Beh, non ero convinto fino a quando non ho cercato di abbracciare la filosofia.
Ho iniziato inserendo const in membri di sola lettura dei miei membri di classe più elementari e argomenti delle funzioni dei membri.
Da lì, non ho potuto compilare più. Quindi ho perseverato nell'entrare nel codice utilizzando quelle classi di base, vedere se le aggiunte const precedenti erano davvero legittime rispetto all'uso che ne facevo. Mi ha aiutato a correggere alcuni bug mentre aggiungevo constness ad altre parti del codice.
È contagioso. La maggior parte del codice ha una costanza ancora maggiore e ho trovato più facile eseguirne il debug perché ti rende sicuro che il compilatore ti fermerà se inizi a modificare qualcosa che non dovresti.
Una volta riavviata l'applicazione, è stato più veloce (ho dovuto modificare alcuni algoritmi che ho scoperto non erano adatti al lavoro), con molti meno bug e più facile da capire durante la lettura del codice.
Ero convinto.
Ora, penso che sia ancora meglio quando usi molte asserzioni oltre a constness perché ti fa sentire sicuro quando devi scrivere un nuovo codice o modificare il codice corrente. Sai che il compilatore ti fermerà se necessario. Ti fa dimenticare di dover controllare tutto ciò che non dovresti modificare e quindi hai più tempo per pensare a un pensiero più specifico per le imprese o al pensiero architettonico.
Non sono mai stato un sostenitore della programmazione orientata agli oggetti, e se mai sono cresciuto di meno, più apprendo sulla programmazione in generale. Poiché ho studiato diversi paradigmi di programmazione, mi sono reso conto che l'immutabilità è uno dei i concetti centrali della progettazione del programma, che influenza il software scritto secondo la filosofia qualsiasi . È estremamente importante nella programmazione funzionale, con implicazioni nell'ottimizzazione e nella concorrenza oltre alle semplici garanzie di sicurezza.
Fondamentalmente, tutto ciò che può essere immutabile probabilmente dovrebbe essere, a meno che tu non abbia una buona ragione per lo stato mutabile. Nella mia esperienza, scrivere programmi in qualsiasi lingua alla ricerca di questo obiettivo porta a un codice migliore più sicuro. Non hai nulla da perdere usando const dove applicabile-l'immutabilità è gratis!
(Per inciso, mi sono divertito con l'idea di creare un fork di GCC per un dialetto di C ++ in cui tutti i tipi sono const a meno che non sia esplicitamente qualificato come mutable . Se c'è un supporto per una cosa del genere, lo farò totalmente impegnato a mantenerlo e ad usarlo.)
Da un punto di vista OO, l'immutabilità impone l'incapsulamento impedendo l'accesso illimitato alla scrittura. Riduce l'accoppiamento tra classi perché gli oggetti immutabili devono gestire completamente il proprio stato e quindi comportarsi come valori ordinari. La correttezza di Const facilita significativamente il processo di dimostrazione della correttezza del programma, specialmente nel contesto della programmazione concorrente. Con la semantica di riferimento di riferimento C ++ e di c ++ 0x rvalue, è possibile utilizzare oggetti immutabili senza preoccuparsi dell'overhead di copiarli dappertutto. Inoltre, il compilatore può funzionare con una magia di ottimizzazione piuttosto sorprendente se stai lavorando con oggetti per lo più immutabili.
So che fa schifo a digitare const ovunque, ma ci si abitua rapidamente e i vantaggi diventano evidenti nel tempo in termini di affidabilità e manutenibilità. Non sono uno scrittore geniale, e sembra essere un compito difficile provato a spiegarcelo, ma so che la correttezza costante mi è stata di immensamente utile come sviluppatore quando progettavo e implementavo programmi, e penso che l'esperienza sia il miglior insegnante in questo senso.
Il vantaggio della correttezza const è che impone una disciplina al programma e rende più facile ragionare su parti del programma.
La disciplina è che devi sapere dove qualcosa potrebbe essere cambiato. Il vantaggio corrispondente è che è più facile vedere cosa fa un pezzo di codice quando puoi dire cosa potrebbe cambiare lo stato.
Essere const correct enfatizza la correttezza del design che trattano vicino a un problema simile che non sta utilizzando operatori cast; quindi non utilizzare cast ed essendo const corretti, utilizzo minimo di mutable - tutti i sono indicatori per misurare quanto è buono il design ma non gli strumenti reali per risolvere il problema generale in mano.
P.S.: Mi sono convinto totalmente di const una volta che ho capito la correttezza nell'usarlo;)
Vedo due motivi principali per scrivere un codice const-correct. Uno è che il compilatore è tuo amico, e usando const ti lasci avvisare di potenziali bug. La seconda ragione è che la cost-correct rende il codice più leggibile. Ad esempio, sai sempre quali argomenti di funzione sono input e quali output. Sai anche quali funzioni membro modificano l'oggetto e quali no. Conosci queste cose istantaneamente senza dover leggere il codice. Questo, naturalmente, presuppone un uso molto giudizioso di const_cast .
Ero un convertito non appena ho saputo che era possibile. Aveva senso per me da un punto di vista di "stile di programmazione buono". Ci sono varie ragioni per le quali è buona pratica essere corretta const:
Per riepilogare due punti che sono coperti in altre risposte e aggiungerne uno nuovo:
const documenta il codice agli utenti della tua API. Forma un contratto tra una funzione e il suo chiamante, che la funzione non modificherà i suoi parametri. (Si noti che const_cast non abilita una funzione a cambiare i suoi parametri, consente di passare quel parametro ad altre funzioni che non modificano i loro parametri ma ha dimenticato l'annotazione const .) È anche utile all'interno di funzioni / loop / etc perché aiuta a comprendere molto allo stesso modo di un ciclo invariante.
const documenta il tuo intento sul compilatore. Trovare errori in fase di compilazione è sempre meglio che aspettare che quel pezzo di codice venga eseguito.
const è necessario per il polimorfismo di tipo sicuro. I puntatori (in tutte le loro forme, non solo i puntatori grezzi) sono solo covarianti se sono const (Nota: non è lo stesso di "puntatore a const"). La covarianza richiede un'interfaccia di sola lettura e la contravarianza richiede un'interfaccia di sola scrittura.
Il secondo di questi ho imparato prima. Ho iniziato con const solo sulla destinazione del puntatore e dei parametri di riferimento, fino a quando ho iniziato a vedere i vantaggi di rilevare gli errori in precedenza e a utilizzarlo sui locali, ecc.
Poi ho appreso che la maggior parte di #define s può essere sostituita (in C ++) da costanti globali, con ulteriori vantaggi di sicurezza del tipo. Quindi l'ho usato anche lì.
Finalmente ho preso una lezione sui sistemi di tipo e sul calcolo lambda, e ho imparato che i tipi const e non- const sono fondamentalmente diversi (poiché supportano diverse operazioni) e da allora non ho mai nemmeno preso in considerazione la scrittura di C ++ codice senza uso intensivo di const .
Ecco i miei 5 centesimi di ciò che non ho visto menzionare negli altri. Quando si passa da una variabile all'altra non si vuole passare per valore, a meno che non sia necessario, per evitare costruzioni extra, distruzioni e copie. Quindi, a meno che non si debba passare per valore, usando i riferimenti ovunque, anche se non si intende cambiare il valore passato si ottiene un aumento significativo delle prestazioni. Per questo motivo, quando hai delle funzioni che prendono riferimenti a tutti i suoi argomenti, devi far sapere al chiamante che cosa la funzione non sta modificando.
È lo stesso principio, ma volevo solo aggiungere un motivo pratico per usare const.
Leggi altre domande sui tag programming-practices c++