Prevenzione di copie non necessarie di oggetti funtore C++

Question

Ho una classe che accumula informazioni su un insieme di oggetti e può agire come un funtore o un iteratore di output. Questo mi permette di fare le cose come:

std::vector<Foo> v; 
Foo const x = std::for_each(v.begin(), v.end(), Joiner<Foo>()); 

e

Foo const x = std::copy(v.begin(), v.end(), Joiner<Foo>()); 

Ora, in teoria, il compilatore dovrebbe essere in grado di utilizzare il copy elision and return-value optimizations in modo che solo un singolo oggetto Joiner deve essere creato. In pratica, tuttavia, la funzione crea una copia su cui operare e quindi la copia nuovamente sul risultato, anche in build completamente ottimizzate.

Se creo il funtore come valore assegnabile, il compilatore crea due copie in più invece di uno:

Joiner<Foo> joiner; 
Foo const x = std::copy(v.begin(), v.end(), joiner); 

Se io goffamente forzare il tipo di modello a un riferimento che passa in un punto di riferimento, ma poi fa una copia di esso comunque e restituisce un riferimento penzoloni alla (ora distrutto) copia temporanea:

x = std::copy<Container::const_iterator, Joiner<Foo>&>(...)); 

posso fare le copie a basso costo utilizzando un riferimento allo stato, piuttosto che lo stato stesso nel funtore in stile di std::inserter, che porta a qualcosa del genere ing come questo:

Foo output; 
std::copy(v.begin(), v.end(), Joiner<Foo>(output)); 

Ma questo rende impossibile usare lo stile "funzionale" di oggetti immutabili, e in generale non è così bello.

C'è qualche modo per incoraggiare il compilatore ad eliminare le copie temporanee, o far passare un riferimento fino in fondo e restituire lo stesso riferimento?

Answer 1

Ti sei imbattuto in un comportamento spesso lamentato con <algorithm>. Non ci sono restrizioni su cosa possono fare con il funtore, quindi la risposta alla tua domanda è no: non c'è modo di incoraggiare il compilatore ad escludere le copie. Non è (sempre) il compilatore, è l'implementazione della libreria. A loro piace solo aggirare i funtori per valore (si pensi a std :: sort che fa un qsort, passando nel funtore per valore alle chiamate ricorsive, ecc.).

Ti sei anche imbattuto nella soluzione esatta che tutti usano: avere un functor mantenere un riferimento allo stato, quindi tutte le copie si riferiscono allo stesso stato quando questo è desiderato.

ho trovato questo ironico:

Ma questo rende impossibile usare lo stile "funzionale" di oggetti immutabili, e in generale non è così bello.

... poiché questa intera domanda si basa su di voi con un complicato stateful functor, dove creare copie è problematico. Se si usassero oggetti immutabili in stile "funzionale", questo sarebbe un non-problema - le copie extra non sarebbero un problema, vero?

Answer 2

RVO è proprio questo - restituire l'ottimizzazione del valore. La maggior parte dei compilatori, oggi, è attivata per impostazione predefinita. Tuttavia, l'argomento che passa è non restituendo un valore. Non puoi aspettarti che una ottimizzazione si adatti a ovunque.

riferiscono a condizioni per copia elision è definita chiaramente 12.8, comma 15, articolo 3.

quando un oggetto classe temporanea che è non è stato legato ad un riferimento (12.2) sarebbe copiato un oggetto classe con stesso cv-qualificato tipo, l'operazione di copia può essere omesso dal costruire l'oggetto temporaneo direttamente nella destinazione del omessa copia

0.123.

[sottolineatura mia]

Il LHS Foo è const qualificato, la temporanea non è. IMHO, questo preclude la possibilità di copia-elisione.

Answer 3

Se si dispone di un compilatore recente (almeno Visual Studio 2008 SP1 o GCC 4.4 credo) è possibile utilizzare std :: Rif/std :: cref

#include <string> 
#include <vector> 
#include <functional> // for std::cref 
#include <algorithm> 
#include <iostream> 

template <typename T> 
class SuperHeavyFunctor 
{ 
    std::vector<char> v500mo; 
    //ban copy 
    SuperHeavyFunctor(const SuperHeavyFunctor&); 
    SuperHeavyFunctor& operator=(const SuperHeavyFunctor&); 
public: 
    SuperHeavyFunctor():v500mo(500*1024*1024){} 
    void operator()(const T& t) const { std::cout << t << std::endl; } 
}; 

int main() 
{ 
    std::vector<std::string> v; v.push_back("Hello"); v.push_back("world"); 
    std::for_each(v.begin(), v.end(), std::cref(SuperHeavyFunctor<std::string>())); 
    return 0; 
} 

Edit: In realtà, l'implementazione del MSVC10 di reference_wrapper non sembra sapere come dedurre il tipo restituito di function object operator(). Ho dovuto derivare SuperHeavyFunctor da std::unary_function<T, void> per farlo funzionare.

Answer 4

Solo una breve nota, for_each, accumulano, trasformare(2 ° modulo), forniscono alcuna garanzia ordine quando si attraversa il campo fornito.

Questo rende il senso per gli implementatori per fornire versioni multithreading/concurrent di queste funzioni.

Perciò, è ragionevole che l'algoritmo sia in grado di fornire un'istanza equivalente (una nuova copia) del funtore passata.

Diffidate momento functors stateful.

Answer 5

Per una soluzione che funzioni con il codice pre-C++ 11, è possibile prendere in considerazione l'uso della funzione boost :: insieme a boost :: ref (come boost::reference_wrapper alone doesn't has an overloaded operator(), diversamente da std :: reference_wrapper che effettivamente funziona). Da questa pagina http://www.boost.org/doc/libs/1_55_0/doc/html/function/tutorial.html#idp95780904, puoi raddoppiare il tuo functor all'interno di un boost: ref quindi un oggetto boost :: function. Ho provato questa soluzione e ha funzionato perfettamente.

Per C++ 11, basta andare con std :: ref e farà il lavoro.