2012-08-09 20 views
9

Apparentemente è buona norma usare const a meno che qualcosa non sia destinato a essere mutabile, ma quanto lontano si va? Se ho una serie di stringhe, la mia firma di funzione dovrebbe includere questo?Const-correctness in C

char const * const * const my_strings 

non intenzione di essere modificarlo sorta, quindi è un puntatore costante al primo elemento di un array di puntatori costanti i primi elementi di array di caratteri costanti. È un boccone e il codice è quasi illeggibile. Tutto questo è una semplice struttura dati come argv.

Mi sento come se const dovrebbe essere l'impostazione predefinita e ci dovrebbe essere una parola chiave mutabile.

Generalmente solo uno di quelli const s? Che senso ha allora, se riesci ancora a cambiarlo facilmente con il dereferenziamento più o meno?

+3

Per la seconda metà della domanda, consultare la [comp.lang.c Domande frequenti 11.10] (http://c-faq.com/ansi/constmismatch.html) –

+0

@JohnBartholomew: Grazie. Non mi rendevo conto che avrei potuto semplicemente trasmettere per far sparire il messaggio. – mk12

+0

Sì, 'const' dovrebbe essere probabilmente il valore predefinito. Credo che Bjarne Stroustup abbia detto la stessa cosa ma ha dovuto mantenere la retrocompatibilità con C. Esiste già una parola chiave 'mutabile'. – bames53

risposta

5

Io in genere uso due dei tre const s:

const char *const *my_strings; 

volte vorrei usare tutti e tre, ma a mio parere l'ultimo è il meno importante. Aiuta solo ad analizzare il codice che utilizza la variabile my_strings, mentre gli altri due aiutano ad analizzare il codice che ha un puntatore all'array puntato da my_strings o alle stringhe puntate dagli elementi di quell'array. Questo è generalmente più codice, in diversi luoghi (ad esempio il chiamante di una funzione e la funzione stessa), e quindi un compito più difficile.

Il codice che utilizza la variabile stessa è limitato all'ambito di my_strings, quindi se questa è una variabile automatica (incluso un parametro di funzione), allora è un compito ben contenuto e facile. L'aiuto fornito contrassegnandolo con const potrebbe ancora essere apprezzato, ma è meno importante.

Direi anche che se char const * const * const my_strings è "quasi illeggibile", allora questo cambierà quando avrai più pratica nella lettura di C, ed è meglio ottenere quella pratica che cambiare il codice. C'è un certo valore nella scrittura del codice C che può essere letto facilmente dai principianti, ma non tanto quanto quello che c'è nel lavoro svolto ;-)

Si potrebbe usare typedefs per rendere la definizione della variabile più corta, al costo di l'introduzione di un riferimento indiretto che infastidire molti programmatori C:

typedef char const *ro_strptr; 
ro_strptr const *my_strings; 

per qualsiasi motivo, i programmatori C spesso vogliono vedere il più possibile di un tipo in un unico luogo. Solo quando il tipo diventa veramente complicato (tipi puntatore-a-funzione) puoi usare un typedef solo per abbreviare, senza aspettarti che qualcuno si lamenti di ciò.

+0

Quasi non leggibile non volevo dire che è difficile da decifrare tanto quanto sembra un sacco di rumore di linea. – mk12

+0

+1 sull'uso di typedefs. Vale la pena notare che la correttezza non può * impedire * a chiunque di modificare i propri dati se lo desiderano. In tal modo non è sempre utile perfezionare la cost-correttezza in questo modo, più indica l'uso previsto. – Scotty

+0

@Scotty: cost-correctness può impedire a un altro codice const-correct di modificare i miei dati. Quindi, se vogliono veramente cambiarlo, ma sono disciplinati, si frenano e il sistema funziona. I programmatori C che non sono disciplinati causano un sacco di comportamenti indefiniti e la modifica degli oggetti const è uno dei molti modi in cui lo fanno :-) Quindi sono d'accordo che indica l'uso previsto, infatti * permesso * l'uso, ma vorrei sottolineare che l'uso previsto/permesso, vale a dire i contratti documentati tra i diversi componenti, è tutto ciò che si trova tra un programma di lavoro e una rovina fumante. –