La scelta tra lambda e functor-class è un compromesso.
Il guadagno di lambda è per lo più sintattico, riducendo al minimo la quantità di piastre e permettendo che il codice concettualmente correlato sia scritto in linea, all'interno della funzione che lo utilizzerà (immediatamente o successivamente).
Per quanto riguarda le prestazioni, questa non è peggio di una classe functor , che è una struct o classe C ++ che contiene un unico "metodo". In effetti, i compilatori trattano Lambda non diversamente da una classe di functor generata dal compilatore dietro la scena.
// define the functor method somewhere
struct some_computer_generated_gibberish_0123456789
{
int operator() (int x) const
{
if (x == 2) return 5;
if (x == 3) return 6;
return 0;
}
};
// make a call
some_computer_generated_gibberish_0123456789 an_instance_of_0123456789;
int outputValue = an_instance_of_0123456789(inputValue);
Nel tuo esempio di codice, per quanto riguarda le prestazioni non è diverso da una chiamata di funzione, perché quella classe di functor non ha uno stato (perché ha una clausola di acquisizione vuota), quindi non richiede allocazione, costruttore o distruzione.
int some_computer_generated_gibberish_0123456789_method_more_gibberish(int x)
{
if (...) return ...;
return ...;
}
Il debug di qualsiasi codice C ++ non banale mediante un disassemblatore è sempre stato un compito difficile. Questo è vero con o senza l'uso di lambda. Questo è causato dalla sofisticata ottimizzazione del codice da parte del compilatore C ++ che ha comportato il riordino, l'interleaving e l'eliminazione del codice morto.
L'aspetto di maneggevolezza dei nomi è alquanto sgradevole e il supporto del debugger per lambda è ancora in la sua infanzia . Si può solo sperare che il supporto del debugger migliorerà nel tempo.
Attualmente, il modo migliore per eseguire il debug del codice lambda è utilizzare un debugger che supporti l'impostazione dei breakpoint a livello di codice sorgente, ad esempio specificando il nome del file di origine e il numero di riga.