puntatori non opzionali vs. riferimenti non costanti in C ++

In Altre funzionalità di C ++, Argomenti di riferimento della Guida allo stile di Google C ++ , ho letto che i riferimenti non costanti non devono essere utilizzati.

Tutti i parametri passati per riferimento devono essere etichettati const.

È chiaro che guardare le chiamate di funzione che usano i riferimenti come argomenti è assolutamente confuso per i programmatori C, ma C e C ++ ora sono linguaggi diversi. Se è richiesto un parametro di output , usando un puntatore per un parametro di output richiesto, si può saltare l'intero corpo della funzione, il che rende più complicata l'implementazione di una funzione (aumenta formalmente la complessità e la profondità ciclomatica di una funzione).

Vorrei rendere il codice C ++ il più semplice possibile da comprendere / mantenere, quindi sono generalmente interessato a leggere le guide di stile di codifica. Ma per quanto riguarda l'adattamento delle migliori pratiche in una squadra, penso che comprendere la logica alla base degli elementi della guida di stile sia un fattore importante.

I riferimenti non costanti sono davvero così negativi? Il loro divieto è solo specifico di Google o è una regola comunemente accettata? Cosa giustifica lo sforzo extra per l'implementazione dei parametri di output come puntatori?

La logica alla base della guida di stile di Google è semplicemente quella di chiarire dal sito di chiamata di una funzione se un parametro è un parametro di input o un parametro di output. (Vedi qui per ulteriori discussioni.) Altre lingue rendono espliciti i parametri in base alla progettazione; C #, ad esempio, ha una outparola chiave che deve essere utilizzata nel sito della chiamata . Poiché C ++ non lo rende esplicito, Google ha scelto di utilizzare const ref. contro il puntatore per chiarire.

È solo una regola di Google? No, ma dubito che sia molto diffuso. Non credo di averlo visto al di fuori della guida di stile e dei gruppi di Google che aderiscono esplicitamente a parti della guida di stile di Google. (Ad esempio, mi è piaciuta l'idea quando ho letto per la prima volta la guida di stile di Google anni fa e l'ho usata per alcuni dei miei codici.)

In particolare, le Linee guida di base C ++ recentemente annunciate preferiscono i valori di ritorno ai parametri di output per (quasi) tutto e usano riferimenti non costanti per il resto. L'uso da parte di Google di puntatori e riferimenti potrebbe rendere più chiari i parametri di output, ma i valori di ritorno sono ancora più chiari. Ora che C ++ 11 ha mosse standardizzate (riferimenti a valori &&, per rendere economici rendimenti di molti tipi) e tuple (che consentono un modo semplice per restituire più valori), molti dei casi d'uso per i parametri di uscita non sono più applicabili.

Le Linee guida di base C ++ hanno alcuni grandi nomi (Bjarne Stroustrup, Herb Sutter) alle spalle, sono supportate da Microsoft e abbracciano le ultime funzionalità C ++ (a differenza della guida di stile di Google), quindi mi aspetto che i suoi consigli siano più popolari di quelli di Google.

Ci sono 2 opzioni per gestire un puntatore non valido passato, primo controllo e ritorno anticipato o lasciare che sia un comportamento indefinito (se ti interessa più la velocità che la robustezza).

Il controllo è semplice come:

void foo(void* buffer){
    if(buffer == nullptr)
        return;

    //actually foo

    // note no increase in indentation required

}

Questo tipo di controllo è generalmente accettato come controllo dei parametri. Se vedi il codice è abbastanza chiaro che ti aspetti che un puntatore non nullo venga passato e che ritorni presto se no. Questo ti consente di non preoccuparti troppo di puntatori non validi.

Dipende dalla tua osservazione If an output parameter is required.

L'unico posto in cui è richiesta una firma di funzione per avere un parametro di output è quando è specificato da un'API esterna, e in tal caso è sufficiente racchiudere l'API esterna in qualcosa che assicuri che sia sempre presente un punto valido.

Internamente si evitano i parametri di output estendendo il tipo restituito per essere un composto di tutti gli "out"