El siguiente programa no se acumula en beta VS11, gcc 4.5 o sonido metálico 3,1std :: hilo con muebles argumento, no copiable
#include <thread>
#include <memory>
int main() {
std::unique_ptr<int> p;
std::thread th([](std::unique_ptr<int>) {
},std::move(p));
th.join();
}
Esto se debe a que el tipo de argumento no es copiable, pero el la implementación intenta copiarlo.
Por lo que puedo decir, este programa está bien formado y debería funcionar. Los requisitos para std :: thread parecen implicar que los argumentos móviles, no copiables, deberían funcionar aquí. Específicamente, dice que el objeto invocable y cada argumento deberán cumplir los requisitos de MoveConstructible, y que INVOKE(DECAY_COPY(std::forward<F>(f)),DECAY_COPY(std::forward<Args>(args))...)
será una expresión válida.
En este caso creo que la expresión se resuelve a algo como:
template <class T> typename std::decay<T>::type decay_copy(T&& v)
{ return std::forward<T>(v); }
std::unique_ptr<int> p;
auto f = [](std::unique_ptr<int>) {};
decay_copy(f)(decay_copy(std::move(p)));
Y no creo que esto se supone que implican una copia de p
. gcc al menos puede compilar esta expresión, aunque VS11 no.
- ¿Me equivoco con respecto a los requisitos y los argumentos deben poder copiarse?
- ¿La norma deja algún margen sobre este tema para que las implementaciones copien argumentos?
- ¿O la implementación intenté no conforme?
Parece que está pasando el argumento de hilo por copia (según la firma de función anónima). ¿No debería el tipo de argumento ser 'std :: unique_ptr &&' o 'const std :: unique_ptr &'? –
@ André: No hay tal cosa como pasar por copia; al pasar el argumento por _value_ se copiará o se moverá dependiendo de si la persona que llama pasa un lvalue o un valor r. – ildjarn
@ildjarn: lo siento, quise decir "por valor", no "por copia". Me pasó por la cabeza que pasar argumentos por valor seleccionará el constructor de movimientos si hay alguno disponible. –