DEFER con RAII & lambda

Spesso è necessario garantire a tutti i costi l’esecuzione di un certo frammento di codice entro lo scope di una funzione, ovvero prima che essa ritorni il controllo al chiamante. Supponiamo di doverci interfacciare con un’API legacy che presenta il classico pattern:

1. InitializeAPI(…) // alloca risorse
2. UseApi(…)
3. …
4. TerminateAPI(…) // libera risorse

Quindi per essere utilizzata, l’API ha prima bisogno di un’inizializzazione e poi alla fine di una terminazione. Una sequenza di questo tipo non è “sicura”:

// exception-unsafe
void IWillUseTheAPI()
{
InitializeAPI();
UseAPI();
// other stuff
TerminateAPI();
}

Cosa accadrebbe infatti se qualcosa (e.g. UseApi) sollevasse un’eccezione prima di arrivare alla chiamata di terminazione? Chiaramente, per com’è scritto il codice, la chiamata a TerminateAPI andrebbe persa causando potenziali problemi al resto del programma.

La soluzione classica a questo problema è di usare l’idioma RAII, ovvero creare un oggetto che inizializzi risorse in costruzione e le rilasci in distruzione; qualcosa del tipo:


class LibWrapper
{
public:
LibWrapper()
{
InitializeAPI();
}

void IWillUseTheAPI()
{
LibWrapper wrapper; // Qui inizializza
wrapper.Use(); // throw? Ok, terminerò lo stesso
} // Termina qui


Il C++ garantisce che in caso di eccezione tutti gli oggetti costruiti sullo stack vengano distrutti (stack unwinding). Nel nostro caso l’istanza di LibWrapper è costruita sullo stack quindi abbiamo la garanzia di chiamare TerminateAPI nel suo distruttore non appena wrapper uscirà dallo scope (ovvero un attimo prima che IwillUseTheAPI ritorni).

La soluzione proposta è chiaramente poco generica. Possiamo allora sfruttare le novità del C++11 per fare ancora di meglio?

Sì. Possiamo implementare la versione più semplice di un DEFER, ovvero un’operazione che rimandi l’esecuzione di un certo codice al termine della funzione in cui compare, anche se viene sollevata un’eccezione. In pseudocodice, qualcosa del tipo:


void IWillUseTheAPI()
{
InitAPI();
DEFER(TerminateAPI()); // sarà eseguito alla fine
//... altre chiamate
}

Grazie alle lambda, possiamo passare codice scritto al volo e tenerlo da parte. Per essere sufficientemente generici, è possibile scrivere un wrapper che riceva in costruzione un qualsiasi oggetto che supporti l’operatore di chiamata a funzione (e.g. una lambda, un funtore, una std::function) e lo “esegua” in distruzione. Sintetizzando:


template <typename F>
struct finalizer
{
template<typename T>
finalizer(T&& f)
: m_f { forward<T>(f) },
m_dismiss { false }
{
}

template <typename F>
finalizer<F> defer(F&& f)
{
return finalizer<F> { std::forward<F>(f) };
}

Perché ho usato il flag m_dismiss e ho scritto il move constructor? Perché, nella chiamata a defer, non è garantito che i compilatori elidano la copia del finalizer – anche se molto probabilmente lo faranno. Chiaramente non è opportuno copiare un finalizer (tutti eseguono m_f?!) ma ci viene in aiuto la move semantics (la responsabilità di eseguire m_f viene trasferita all’ultimo finalizer).

Universal references (e.g. F&&) e forward servono ad evitare potenziali copie (ma è anche possibile passare tutto per valore e fare delle move). Il codice è semplice, non fa altro che tenere da parte una “funzione” (in realtà un oggetto che sa comportarsi come tale) e poi eseguirla in distruzione.

Come utilizzare tutto questo? Così:


void IWillUseTheAPI()
{
InitAPI();
auto defer_1 = defer([]{ TerminateAPI(); });
// ...
}

Non vi piace? Concordo! Usiamo una semplicissima macro per evitare di dare un nome ad un oggetto che non dovrà più essere utilizzato e per esplicitare la semantica di quello che stiamo facendo:


// generalmente tutti hanno queste (o di più generiche) due nella propria codebase 🙂
#define PASTE_STRING(arg1, arg2) DO_PASTE_STRING(arg1, arg2)
#define DO_PASTE_STRING(arg1, arg2) arg1 ## arg2

#define DEFER(...) auto PASTE_STRING(defer_, __LINE__) = defer(__VA_ARGS__)
// e.g. auto defer_13 = defer(...)
E finalmente:

void IWillUseTheAPI()
{
InitAPI();
DEFER([]{ TerminateAPI(); }); // sarà eseguito alla fine
//... altre chiamate
}

Questa è stata una delle primissime utility che ho inserito nella mia libreria di supporto! Poco tempo dopo ho scoperto che già ci aveva pensato Alexandrescu e consiglio a tutti la visione del video (specialmente la prima parte, molto più deep di quella sullo ScopeGuard – l’equivalente del nostro DEFER).

Ricapitolando:

• No ad una cattiva struttura del codice che può portare problemi di exception-safety,
• Sì all’utilizzo dell’idioma RAII,
• Sì++ se riusciamo ad essere non solo safe ma anche generici e flessibili. DEFER è solo un semplice esempio!