In alcuni casi, faccio un std::find_if
(ad esempio) in una funzione locale che ha 5 variabili locali, inclusi i parametri. Tuttavia, il lambda I che passa nell'algoritmo STL ha solo bisogno di accedere a 1 di questi. Ho potuto catturare questo in uno dei due modi:Quando preferire l'acquisizione esplicita in lambda rispetto alle acquisizioni implicite?
void foo(int one, int two, int three)
{
std::vector<int> m_numbers;
int four, five;
std::find_if(m_numbers.begin(), m_numbers.end(), [=](int number) {
return number == four;
});
}
O posso fare:
void foo(int one, int two, int three)
{
std::vector<int> m_numbers;
int four, five;
std::find_if(m_numbers.begin(), m_numbers.end(), [four](int number) {
return number == four;
});
}
(nota non ho compilare questo codice, le scuse per eventuali errori di sintassi o altri errori)
So che le acquisizioni implicite si basano sulle odr-used, quindi, dal punto di vista funzionale e di implementazione, penso che entrambe siano identiche. Quando useresti le acquisizioni esplicite su quelle implicite? Il mio unico pensiero è in qualche modo legato ai principi di incapsulamento: avere accesso solo alle cose che ti servono permette al compilatore di aiutarti a determinare quando accedi a una variabile che non dovresti. Mantiene anche lo stato locale del metodo (è invariante, per tutta la durata della funzione durante la sua esecuzione) più sicuro. Ma queste sono preoccupazioni veramente pratiche?
Esistono motivi funzionali per utilizzare le acquisizioni esplicite su quelle implicite? Che cosa è una buona regola empirica o la migliore pratica da seguire?
IIRC, Scott Meyers suggerisce (nel suo libro più recente) usare praticamente solo cattura impliciti in casi come questo, in cui è un argomento per una funzione che lo usa e non lo tiene in giro. Ci sono, naturalmente, esempi di trappole in cui puoi cadere quando usi acquisizioni implicite in vari scenari. – chris
Gli esempi di tali trappole sarebbero molto apprezzati. Questi esempi aiuteranno a contrastare le differenze e aiutano a stabilire buone regole generali di pratica. –
@chris La raccomandazione di Scott Meyers va diversamente. Effective Modern C++, Item 31: Evita le modalità di acquisizione predefinite. – LogicStuff