Per la questione dell’include, Crayon (il syntax highlighter usato per postare codice) non dovrebbe aver problemi con maggiori/minori e virgolette.

Oltre ai commenti che avevo fatto su linkedin, vorrei aggiungere una soluzione alternativa che fa uso delle librerie boost, ovvero di scope_exit, che va bene anche in C++98/03 e che, a mio avviso, resta leggibile anche in C++11, nonostante il supporto per le lambda-expressions:

#include 

void IWillUseTheAPI() {
   Init();
   BOOST_SCOPE_EXIT(void) { // SCOPE_EXIT supporta la lista di cattura
        Terminate(); // nothrow/noexcept
   }
   BOOST_SCOPE_EXIT_END
   // ...
}

1) assolutamente sì! Io mi sono ispirato dal GO, visto in ufficio da un mio collega.

2) concordo, non l’ho scritto per semplicità ma hai fatto benissimo a scriverlo nei commenti.

anche io mi sono fatto un po’ “di ginnastica mentale” su quest’argomento, e volevo contribuire con un paio di osservazioni:

1) la prima volta che ho visto questo paradigma è stato quando studiai il linguaggio D (dietro cui c’è sempre Alexandrescu), e comunque anche la libreria boost offre alcune soluzioni analoghe (vedi scope_exit).

2) la seconda è più sostanziale: essendo chiamato all’interno di un distruttore, il codice passato al DEFER NON deve lanciare eccezioni. Il motivo è semplice: se la DEFER viene invocata durante lo stack unwinding dovuto ad un eccezione, ed il codice a sua volta lancia un’altra accezione, avremmo due eccezioni contemporaneamente; lo standard in questo caso richiederebbe l’invocazione di std::terminate().

My 2¢

In generale, secondo me ci sono due utilizzi interessanti del DEFER:

1) quando vuoi eseguire del codice “semplice” alla fine di una funzione. Per semplice intendo che non faccia cose per cui sarebbe opportuno un oggetto a parte. In questo caso ricade l’esempio dell’API se l’utilizzo è confinato in un solo punto. Altri esempi sono logging (e.g. vuoi a tutti i costi loggare l’uscita da una funzione – anche in caso di eccezione) e profilazione.

2) quando vuoi scrivere codice prototipale. Riprendi l’esempio dell’API, magari stai scrivendo un codice che si interfaccia con una libreria esterna. Fai una prima prova usando DEFER, tutto funziona e non hai dovuto scrivere nessun wrapper. Poi ti rendi conto che userai l’API in un secondo punto. Allora introduci un oggetto più intelligente. In questo senso DEFER ti ha anche aiutato a fare una piccola scelta di design, senza però toglierti la possibilità di: (1) provare in fretta la struttura del tuo codice, (2) essere conformi agli idiomi del C++ (RAII). Chiaramente il rovescio della medaglia è lasciare il codice con due DEFER, che potrebbe non essere l’ideale 🙂 Ma qui si cade, poi, nel dover distinguere prototipazione e produzione, che spesso dipende dal proprio buon senso e da tanti altri fattori che farebbero andare troppo fuori tema questo commento!

Ma con il wrapper “base” potrei nascondere i “dettagli tecnici”. Usando il wrapper non ho la preoccupazione di proteggere ogni uso della libreria con DEFER(…). Il codice/algoritmo sarebbe semplificato, senza queste “distrazioni”.

Quali sono le linee guida in questo caso?
Quando è meglio (o necessario) usare direttamente DEFER piuttosto che creare il wrapper?