Quando dovrei davvero usare noexcept?

La noexceptparola chiave può essere applicata in modo appropriato a molte firme di funzioni, ma non sono sicuro di quando dovrei considerare di usarlo nella pratica. Sulla base di ciò che ho letto finora, l'aggiunta dell'ultimo minuto noexceptsembra affrontare alcuni problemi importanti che sorgono quando si lanciano costruttori di mosse. Tuttavia, non sono ancora in grado di fornire risposte soddisfacenti ad alcune domande pratiche che mi hanno portato a leggere di più noexceptin primo luogo.

1. Ci sono molti esempi di funzioni che conosco non verranno mai lanciate, ma per le quali il compilatore non può determinarlo da solo. Devo aggiungere noexceptalla dichiarazione di funzione in tutti questi casi?

   Dover pensare se devo aggiungere o meno noexceptdopo ogni dichiarazione di funzione ridurrebbe notevolmente la produttività del programmatore (e francamente, sarebbe un dolore nel culo). Per quali situazioni dovrei essere più attento all'uso noexcepte per quali situazioni posso cavarmela con l'implicito noexcept(false)?

2. Quando posso realisticamente aspettarmi di osservare un miglioramento delle prestazioni dopo l'uso noexcept? In particolare, fornire un esempio di codice per il quale un compilatore C ++ è in grado di generare un codice macchina migliore dopo l'aggiunta di noexcept.

   Personalmente, mi preoccupo per noexceptla maggiore libertà fornita al compilatore di applicare in modo sicuro alcuni tipi di ottimizzazioni. I compilatori moderni ne traggono vantaggio noexceptin questo modo? In caso contrario, posso aspettarmi che alcuni di loro lo facciano nel prossimo futuro?

Penso che sia troppo presto per dare una risposta "best practice" per questo in quanto non c'è stato abbastanza tempo per usarlo nella pratica. Se questo fosse stato chiesto degli indicatori di lancio subito dopo la loro uscita, le risposte sarebbero molto diverse da adesso.

Dover pensare se devo aggiungere o meno noexceptdopo ogni dichiarazione di funzione ridurrebbe notevolmente la produttività del programmatore (e francamente, sarebbe una seccatura).

Bene, allora usalo quando è ovvio che la funzione non verrà mai lanciata.

Quando posso realisticamente aspettarmi di osservare un miglioramento delle prestazioni dopo l'uso noexcept? [...] Personalmente, mi preoccupo per noexceptla maggiore libertà fornita al compilatore di applicare in modo sicuro determinati tipi di ottimizzazioni.

Sembra che i maggiori guadagni di ottimizzazione derivino dalle ottimizzazioni degli utenti, non da quelle del compilatore a causa della possibilità di verificarle noexcepte sovraccaricarle. La maggior parte dei compilatori segue un metodo di gestione delle eccezioni senza penalità se non si lancia, quindi dubito che cambierebbe molto (o niente) a livello di codice macchina del codice, sebbene forse riduca le dimensioni binarie rimuovendo il codice di gestione.

L'uso noexceptnei quattro principali (costruttori, assegnazione, non distruttori come già sono noexcept) probabilmente causerà i migliori miglioramenti poiché i noexceptcontrolli sono "comuni" nel codice modello come nei stdcontenitori. Ad esempio, std::vectornon utilizzerà la mossa della tua classe a meno che non sia contrassegnata noexcept(o altrimenti il ​​compilatore non può dedurla in altro modo).

Come continuo a ripetere in questi giorni: prima la semantica .

Aggiungendo noexcept, noexcept(true)ed noexcept(false)è prima di tutto sulla semantica. Per inciso condiziona solo una serie di possibili ottimizzazioni.

Come programmatore che legge il codice, la presenza di noexceptè simile a quella di const: mi aiuta a capire meglio cosa può o non può accadere. Pertanto, vale la pena dedicare un po 'di tempo a pensare se si sa se la funzione verrà lanciata. Per un promemoria, può essere lanciato qualsiasi tipo di allocazione dinamica della memoria.

Bene, ora passiamo alle possibili ottimizzazioni.

Le ottimizzazioni più ovvie vengono effettivamente eseguite nelle librerie. C ++ 11 fornisce una serie di tratti che consente di sapere se una funzione è noexcepto meno e l'implementazione della Libreria standard stessa utilizzerà tali tratti per favorire le noexceptoperazioni sugli oggetti definiti dall'utente che manipolano, se possibile. Come spostare la semantica .

Il compilatore può solo eliminare un po 'di grasso (forse) dai dati di gestione delle eccezioni, perché deve tenere conto del fatto che potresti aver mentito. Se viene lanciata una funzione contrassegnata noexcept, std::terminateviene chiamata.

Queste semantiche sono state scelte per due motivi:

• beneficiando immediatamente noexceptanche quando le dipendenze non lo utilizzano già (compatibilità con le versioni precedenti)
• consentendo la specifica di noexceptquando si chiamano funzioni che teoricamente possono essere lanciate, ma che non sono previste per gli argomenti dati

Questo in realtà fa una differenza (potenzialmente) enorme per l'ottimizzatore nel compilatore. I compilatori hanno effettivamente avuto questa funzione per anni tramite l'istruzione empty throw () dopo una definizione di funzione, nonché estensioni di proprietà. Posso assicurarti che i compilatori moderni sfruttano questa conoscenza per generare codice migliore.

Quasi ogni ottimizzazione nel compilatore utilizza qualcosa chiamato "diagramma di flusso" di una funzione per ragionare su ciò che è legale. Un diagramma di flusso è costituito da quelli che vengono generalmente chiamati "blocchi" della funzione (aree di codice che hanno una singola entrata e una singola uscita) e bordi tra i blocchi per indicare dove può passare il flusso. Noexcept modifica il diagramma di flusso.

Hai chiesto un esempio specifico. Considera questo codice:

void foo(int x) {
    try {
        bar();
        x = 5;
        // Other stuff which doesn't modify x, but might throw
    } catch(...) {
        // Don't modify x
    }

    baz(x); // Or other statement using x
}

Il diagramma di flusso per questa funzione è diverso se barè etichettato noexcept(non è possibile che l'esecuzione salti tra la fine di bare l'istruzione catch). Se etichettato come noexcept, il compilatore è certo che il valore di x è 5 durante la funzione baz - si dice che il blocco x = 5 "domina" il blocco baz (x) senza il bordo bar()dall'istruzione catch.

Può quindi fare qualcosa chiamato "propagazione costante" per generare codice più efficiente. Qui se baz è inline, le istruzioni che usano x potrebbero contenere anche costanti e quindi quella che era una valutazione di runtime può essere trasformata in una valutazione in fase di compilazione, ecc.

Comunque, la risposta breve: noexceptconsente al compilatore di generare un diagramma di flusso più stretto e il diagramma di flusso viene utilizzato per ragionare su tutti i tipi di ottimizzazioni del compilatore comuni. Per un compilatore, le annotazioni degli utenti di questa natura sono fantastiche. Il compilatore proverà a capire queste cose, ma di solito non ci riesce (la funzione in questione potrebbe trovarsi in un altro file oggetto non visibile al compilatore o usare in modo transitorio alcune funzioni che non sono visibili), oppure quando lo fa, c'è qualche banale eccezione che potrebbe essere lanciata di cui non sei nemmeno a conoscenza, quindi non può implicitamente etichettarla come noexcept(allocando la memoria potrebbe generare bad_alloc, per esempio).

noexceptpuò migliorare notevolmente le prestazioni di alcune operazioni. Ciò non avviene a livello di generazione del codice macchina da parte del compilatore, ma selezionando l'algoritmo più efficace: come altri hanno già detto, si effettua questa selezione utilizzando la funzione std::move_if_noexcept. Ad esempio, la crescita di std::vector(ad esempio, quando chiamiamo reserve) deve fornire una forte garanzia di sicurezza delle eccezioni. Se sa che Til costruttore di mosse non viene lanciato, può semplicemente spostare ogni elemento. Altrimenti deve copiare tutti Ti messaggi. Questo è stato descritto in dettaglio in questo post .

Quando posso realisticamente, tranne osservare un miglioramento delle prestazioni dopo l'uso noexcept? In particolare, fornisci un esempio di codice per il quale un compilatore C ++ è in grado di generare un codice macchina migliore dopo l'aggiunta di noexcept.

Uhm, mai? Non è mai un momento? Mai.

noexceptè per le ottimizzazioni delle prestazioni del compilatore allo stesso modo constdelle ottimizzazioni delle prestazioni del compilatore. Cioè, quasi mai.

noexceptviene utilizzato principalmente per consentire a "voi" di rilevare in fase di compilazione se una funzione può generare un'eccezione. Ricorda: la maggior parte dei compilatori non emette codice speciale per le eccezioni a meno che non generi effettivamente qualcosa. Quindi noexceptnon si tratta di dare suggerimenti al compilatore su come ottimizzare una funzione, ma piuttosto di darti suggerimenti su come usare una funzione.

I modelli come move_if_noexceptrileveranno se il costruttore di mosse è definito con noexcepte restituiranno un const&invece di un &&tipo se non lo è. È un modo per dire di muoversi se è molto sicuro farlo.

In generale, dovresti usarlo noexceptquando pensi che sarà effettivamente utile farlo. Alcuni codici avranno percorsi diversi se is_nothrow_constructibleè vero per quel tipo. Se stai usando un codice che lo farà, sentiti libero con noexcepti costruttori appropriati.

In breve: usalo per spostare costruttori e costrutti simili, ma non pensare di dover impazzire con esso.

Con le parole di Bjarne ( The C ++ Programming Language, 4th Edition , page 366):

Laddove la risoluzione sia una risposta accettabile, un'eccezione non rilevata la raggiungerà perché si trasforma in una chiamata di terminate () (§13.5.2.5). Inoltre, uno noexceptspecificatore (§13.5.1.1) può rendere esplicito quel desiderio.

I sistemi di tolleranza agli errori di successo sono multilivello. Ogni livello affronta quanti più errori possibile senza essere troppo contorto e lascia il resto a livelli più alti. Le eccezioni supportano tale visualizzazione. Inoltre, terminate()supporta questa visione fornendo una via di fuga se il meccanismo di gestione delle eccezioni stesso è corrotto o se è stato usato in modo incompleto, lasciando quindi le eccezioni non rilevate. Allo stesso modo, noexceptfornisce una semplice via di fuga per errori in cui il tentativo di recupero sembra impossibile.

double compute(double x) noexcept;     {
    string s = "Courtney and Anya";
    vector<double> tmp(10);
    // ...
}

Il costruttore di vettori potrebbe non riuscire ad acquisire memoria per i suoi dieci doppi e lanciare a std::bad_alloc. In tal caso, il programma termina. Termina incondizionatamente invocando std::terminate()(§30.4.1.3). Non invoca i distruttori dalle funzioni di chiamata. È definito dall'implementazione se vengono invocati i distruttori dagli ambiti tra il throwe il noexcept(es. Per s in compute ()). Il programma sta per terminare, quindi non dovremmo comunque dipendere da alcun oggetto. Aggiungendo uno noexceptspecificatore, indichiamo che il nostro codice non è stato scritto per far fronte a un lancio.

1. Ci sono molti esempi di funzioni che conosco non verranno mai lanciate, ma per le quali il compilatore non può determinarlo da solo. Devo aggiungere noexcept alla dichiarazione di funzione in tutti questi casi?

noexceptè complicato, poiché fa parte dell'interfaccia delle funzioni. In particolare, se si sta scrivendo una libreria, il codice client può dipendere dalla noexceptproprietà. Può essere difficile modificarlo in un secondo momento, poiché potresti rompere il codice esistente. Potrebbe essere meno preoccupante quando si implementa il codice utilizzato solo dalla propria applicazione.

Se hai una funzione che non può essere lanciata, chiediti se rimarrà tale noexcepto limiterebbe le future implementazioni? Ad esempio, potresti voler introdurre il controllo degli errori di argomenti illegali lanciando eccezioni (ad esempio, per i test unitari), oppure potresti dipendere da un altro codice di libreria che potrebbe modificare le sue specifiche di eccezione. In tal caso, è più sicuro essere conservatori e omettere noexcept.

D'altra parte, se si è certi che la funzione non debba mai essere lanciata ed è corretto che faccia parte delle specifiche, è necessario dichiararla noexcept. Tuttavia, tieni presente che il compilatore non sarà in grado di rilevare violazioni noexceptse l'implementazione cambia.

2. Per quali situazioni dovrei essere più attento all'uso di noexcept e per quali situazioni posso cavarmela con il noexcept implicito (falso)?

Esistono quattro classi di funzioni su cui dovresti concentrarti perché probabilmente avranno il maggiore impatto:

1. operazioni di spostamento (sposta operatore di assegnazione e sposta costruttori)
2. operazioni di scambio
3. deallocatori di memoria (eliminazione operatore, eliminazione operatore [])
4. distruttori (anche se questi sono implicitamente a noexcept(true)meno che tu non li crei noexcept(false))

Queste funzioni dovrebbero essere generalmente noexcepted è molto probabile che le implementazioni della libreria possano utilizzare la noexceptproprietà. Ad esempio, è std::vectorpossibile utilizzare operazioni di movimento senza lancio senza sacrificare forti garanzie di eccezione. Altrimenti, dovrà ricorrere agli elementi di copia (come in C ++ 98).

Questo tipo di ottimizzazione è a livello algoritmico e non si basa su ottimizzazioni del compilatore. Può avere un impatto significativo, soprattutto se gli elementi sono costosi da copiare.

3. Quando posso realisticamente aspettarmi di osservare un miglioramento delle prestazioni dopo aver usato noexcept? In particolare, fornisci un esempio di codice per il quale un compilatore C ++ è in grado di generare un codice macchina migliore dopo l'aggiunta di noexcept.

Il vantaggio di noexceptnon specificare alcuna eccezione o throw()è che lo standard consente ai compilatori una maggiore libertà quando si tratta di impilare lo svolgimento. Anche nel throw()caso, il compilatore deve svolgere completamente lo stack (e deve farlo nell'esatto ordine inverso delle costruzioni di oggetti).

Nel noexceptcaso, d'altra parte, non è necessario farlo. Non è richiesto che lo stack debba essere svolto (ma al compilatore è ancora consentito farlo). Questa libertà consente un'ulteriore ottimizzazione del codice in quanto riduce il sovraccarico di essere sempre in grado di svolgere lo stack.

La domanda correlata su noexcept, svolgimento della pila e prestazioni va in maggiori dettagli sull'overhead quando è richiesto lo svolgimento della pila.

Raccomando anche il libro di Scott Meyers "Effective Modern C ++", "Articolo 14: Dichiarare le funzioni tranne se non emetteranno eccezioni" per ulteriori letture.

Ci sono molti esempi di funzioni che conosco non verranno mai lanciate, ma per le quali il compilatore non può determinarlo da solo. Devo aggiungere noexcept alla dichiarazione di funzione in tutti questi casi?

Quando dici "So che [non] non lanceranno mai", intendi esaminando l'implementazione della funzione, sai che la funzione non verrà lanciata. Penso che questo approccio sia capovolto.

È meglio considerare se una funzione può generare eccezioni come parte del progetto della funzione: importante quanto l'elenco degli argomenti e se un metodo è un mutatore (... const). Dichiarare che "questa funzione non genera eccezioni" è un vincolo per l'implementazione. Ometterlo non significa che la funzione potrebbe generare eccezioni; significa che la versione corrente della funzione e tutte le versioni future potrebbero generare eccezioni. È un vincolo che rende più difficile l'implementazione. Ma alcuni metodi devono avere il vincolo per essere praticamente utili; soprattutto, in modo che possano essere chiamati dai distruttori, ma anche per l'implementazione del codice "roll-back" in metodi che forniscono la forte garanzia di eccezione.