Impedir copias innecesarias de los objetos del functor C++

Question

Tengo una clase que acumula información sobre un conjunto de objetos y puede actuar como un funtor o como un iterador de salida. Esto me permite hacer cosas como:

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

y

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

Ahora, en teoría, el compilador debe ser capaz de utilizar el copy elision and return-value optimizations por lo que sólo un único Joiner objeto necesita ser creado. En la práctica, sin embargo, la función hace una copia sobre la cual operar y luego copia eso de vuelta al resultado, incluso en versiones completamente optimizadas.

Si creo el funtor como un valor-I, el compilador crea dos copias extra en lugar de uno:

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

Si torpemente fuerzo el tipo de plantilla a una referencia que pasa una referencia, pero luego hace una copia de todos modos y devuelve una referencia que cuelga a la (ahora destruido) copia temporal:

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

que puede hacer las copias baratas utilizando una referencia al estado en lugar del propio estado en el funtor en el estilo de std::inserter, lo que lleva a algo ing así:

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

Pero esto hace que sea imposible utilizar el estilo "funcional" de los objetos inmutables, y en general no es tan agradable.

¿Hay alguna forma de alentar al compilador a eludir las copias temporales, o hacer que pase una referencia hasta el final y devolver esa misma referencia?

Answer 1

Ha tropezado con un comportamiento a menudo quejado con <algorithm>. No hay restricciones sobre lo que pueden hacer con el funtor, por lo que la respuesta a su pregunta es no: no hay forma de alentar al compilador a eludir las copias. No es (siempre) el compilador, es la implementación de la biblioteca. Simplemente les gusta pasar los funtores por valor (piense en std :: sort haciendo un qsort, pasando el functor por valor a llamadas recursivas, etc.).

También ha tropezado con la solución exacta que todo el mundo utiliza: haga que un functor mantenga una referencia al estado, por lo que todas las copias se refieren al mismo estado cuando se desee.

yo encontramos este irónico:

pero esto hace que sea imposible utilizar el estilo "funcional" de los objetos inmutables, y en general no es tan agradable.

... ya que toda esta pregunta se basa en que tiene un functor con estado complicado, donde la creación de copias es problemática. Si estuvieras usando objetos inmutables de estilo "funcional", esto no tendría importancia, las copias adicionales no serían un problema, ¿o sí?

Answer 2

RVO es solo eso - return valor optimizado. La mayoría de los compiladores, hoy en día, lo tienen activado por defecto. Sin embargo, el argumento que pasa es no devolviendo un valor. Posiblemente no se puede esperar que una optimización encaje en todas partes.

se refieren a condiciones para elision copia se define claramente en 12,8, párrafo 15, punto 3.

cuando un objeto de clase temporal que no ha sido atado a una referencia (12.2) sería copiado a un objeto de clase con la misma cv-incondicional tipo, la operación de copia se puede omitir por construir el objeto temporal directamente en el objetivo de la omitido copia

[el énfasis es mío]

El LHS Foo es const cualificado, el temporal no es. En mi humilde opinión, esto excluye la posibilidad de copia-elisión.

Answer 3

Si usted tiene un compilador reciente (Al menos Visual Studio 2008 SP1 o GCC 4.4 creo) se puede utilizar std :: ref/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; 
} 

Editar: En realidad, la implementación de la MSVC10 reference_wrapper no parece saber cómo deducir el tipo de retorno del operador de objeto de función(). Tuve que derivar SuperHeavyFunctor de std::unary_function<T, void> para hacerlo funcionar.

Answer 4

Sólo una nota rápida, for_each, acumulan, transformada(segunda forma), no ofrecen ninguna garantía de orden cuando se atraviesa el rango previsto.

Esto hace sentido para los implementadores para proporcionar versiones multiproceso/simultáneas de estas funciones.

Por lo tanto es razonable que el algoritmo sea capaz de proporcionar una instancia equivalente (una nueva copia) de la funtor aprobada en.

Tenga cuidado al hacer funtores con estado.

Answer 5

Para una solución que funcione con el código pre-C++ 11, puede considerar el uso de la función boost :: junto con boost :: ref (como boost::reference_wrapper alone doesn't has an overloaded operator(), a diferencia de std :: reference_wrapper que sí lo hace). Desde esta página http://www.boost.org/doc/libs/1_55_0/doc/html/function/tutorial.html#idp95780904, puede envolver doblemente su functor dentro de un boost :: ref luego un objeto boost :: function. Intenté con esa solución y funcionó a la perfección.

Para C++ 11, puede simplemente ir con std :: ref y hará el trabajo.