2012-04-03 23 views
9

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.

  1. ¿Me equivoco con respecto a los requisitos y los argumentos deben poder copiarse?
  2. ¿La norma deja algún margen sobre este tema para que las implementaciones copien argumentos?
  3. ¿O la implementación intenté no conforme?
+0

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 &'? –

+2

@ 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

+1

@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. –

Respuesta

14

De 30.3.1.2, párrafo 3 y 4 de N3337:

template <class F, class ...Args> explicit thread(F&& f, Args&&... args);

Requiere: F y cada Ti en Args deberán satisfacer la MoveConstructible requisitos. INVOKE (DECAY_-COPY (std::forward<F>(f)), DECAY_COPY (std::forward<Args>(args))...) (20.8.2) debe ser una expresión válida.

Efectos: Construye un objeto de tipo hilo. El nuevo hilo de ejecución ejecuta INVOKE (DECAY_-COPY (std::forward<F>(f)), DECAY_COPY (std::forward<Args>(args))...) con las llamadas a DECAY_COPY siendo evaluadas en el hilo de construcción. Cualquier valor de retorno de esta invocación se ignora. [Nota: Esto implica que cualquier excepción no lanzada desde la invocación de la copia de f se arrojará en el hilo de construcción, no en el nuevo hilo. -finalizar nota] Si la invocación de INVOKE (DECAY_COPY (std::forward<F>(f)), DECAY_COPY (std::forward<Args>(args))...) finaliza con una excepción no detectada, se llamará a std :: terminate.

Así que sí, esto debería funcionar. Si no es así, entonces es un error en su implementación.

Tenga en cuenta que cualquier movimiento/copia de parámetros ocurrirá en el nuevo hilo. Estás pasando referencias a otro hilo, por lo que debes asegurarte de que sigan existiendo hasta que comience el hilo.

+2

Y funciona con g ++, a partir de la versión 4.7 – je4d

+0

Y ahora ya no puedo reproducir el error en clang, aunque el código que utilicé anteriormente está en un repositorio fuente y tengo la línea de comando exacta en mi historial. Supongo que debería volver a verificar el vs11 también. – bames53

+1

En realidad, parece que el problema era una versión anterior de libC++ frente a la última. – bames53

3

Como alternativa, y como el std::thread lenguaje estándar, puede pasar una envoltura de referencia:

int p; 
std::thread([](int & x) { /* ... */ }, std::ref(p)); 

Esto crea un objeto de tipo std::reference_wrapper<int>, que tiene la semántica de valor y envuelve una referencia a un int (es decir, copiando el envoltorio alias la referencia).

Cuestiones relacionadas