semantica const per accesso al database o al filesystem

Question

Io uso regolarmente const quando lavoro con strutture dati in memoria e mantengo il mio codice costante, ma non sono sicuro di come const debba applicarsi a oggetti più complessi, come il seguente:

• oggetti che rappresentano connessioni a sistemi remoti
• oggetti supportati da un database (che possono caricare parti dal database su richiesta)
• oggetti supportati da un albero di directory su disco (con accesso alla struttura di directory controllato da una gerarchia di oggetti separata)

Cosa devono significare i metodi const per oggetti come questi? Mi viene in mente un paio di possibilità:

• "severe" Const - I metodi che non modificano qualsiasi stato in memoria sono const. Tuttavia, ciò sembrerebbe interrompere l'incapsulamento, poiché richiederebbe ai chiamanti di sapere quali metodi modificano lo stato della connessione e quali no.
• "logico" const - I metodi che non modificano lo stato logico dell'oggetto sono const. Tuttavia, questo potrebbe richiedere la marcatura di molte variabili di stato e di memorizzazione nella cache come mutable. Anche se mi rendo conto che è quello per cui è stato progettato lo standard mutable, utilizzarlo sembra un trucco. Inoltre, dato che const significa "Prometto di non modificare questo", non sembra giusto applicarlo quando i metodi possono modificare lo stato della connessione in modi strani e meravigliosi (purché mantengano l'incapsulamento), i risultati della cache come tanto quanto vogliono, lanciare eccezioni se la connessione fallisce, ecc.
• No const - Alla luce dei problemi precedenti, const semplicemente non ha molto significato per oggetti più complicati?

Quale approccio è più utile? Qual è il più comune?

Answer 1

Questa è una domanda difficile. In questo momento sto lavorando alla stessa cosa. Ho una grande struttura dati in memoria supportata da un database MySQL. Ho iniziato con un approccio "const ove possibile", ma che si rivela essere non molto spesso, in pratica:

• Si potrebbe utilizzare una libreria di terze parti che non è const-corretto.
• Non tutte le istruzioni SELECT sono in realtà di sola lettura. Ad esempio, SELECT GET_LOCK modifica decisamente lo stato sul lato db.
• Non ho incontrato molti programmatori C++ che possono utilizzare correttamente mutable. Certamente non ho molta esperienza con questo. I futuri manutentori potrebbero causare più problemi di quanti ne potrebbero risolvere. Conosci meglio la tua squadra, quindi sta a te decidere se vuoi seguire quella strada.

Penso che un oggetto const con un singolo handle mutabile nel database potrebbe essere la soluzione più elegante. Decidi cosa un oggetto const dovrebbe essere ragionevolmente in grado di fare e rendere costanti tutte quelle funzioni. Gli utenti della tua classe devono solo sapere quali funzioni sono const e quali no. Il file di intestazione darà loro quello. Non dovrebbero avere bisogno di sapere perché una funzione particolare è const o non-const. Sono d'accordo però che una pila di membri mutabili inizi a sembrare hackish.

Nel mio caso, sostanzialmente ho dovuto rinunciare alla correttezza.Un oggetto const sarebbe stato così ammanettato da non poter fare nulla di utile. Sulla base dei miei anni di esperienza, sospetto che questo sia ciò che di solito accade nella pratica. La cost-correctness logica è un ottimo ideale (e dovresti sicuramente iniziare da lì se stai costruendo da zero), ma quando si tratta di codice di spedizione reale, no const è la strada da percorrere.