¿Puede queue :: pop devolver un valor ahora?

Question

Sé std::queue::pop() devuelve void. Por dos razones: la seguridad

1. excepción: algo podría lanzar después de retirar el elemento
2. para poder return the value by reference

fina.

Ahora si entiendo la nueva semántica de movimiento de C++ 11 correctamente, la segunda ya no es un argumento válido.

Entonces ... ¿lo único que impide que std::queue tenga una función de tipo pop que devuelve el valor reside en la posibilidad de que el constructor de movimiento lance?

Me resulta difícil pensar en situaciones en las que un constructor de movimientos así lanzaría. ¿Quién sabe de un ejemplo?

supongo que lo mismo vale para std::stack::pop(), std::vector::pop_front(), std::vector::pop_back(), std::deque::pop_front(), std::deque::pop_back(), std::list::pop_front(), std::list::pop_back() y lo que no.

Answer 1

Utilizando técnicas SFINAE inteligentes efectivamente sería posible tener una pop_and_move no tirar atómica() por sólo tipos de datos que implementan sin tirar ningún movimiento o tirar-copia.

Incluso hay un constructo noexcept() disponible para ver si algo puede arrojar.

Uno de los nuevos conceptos en C++ 11 en particular que extiende SFINAE es que si el cuerpo no compila la función no existe. Por lo tanto, uno podría implementar basado en noexcept().

Diría que por compatibilidad con versiones anteriores la función necesitaría un nuevo nombre, que por lo tanto le permite coexistir con la funcionalidad existente de llamarlas por separado, sin romper contenedores de tipos que no tienen la semántica para permitirlo.

Answer 2

No hay muchos casos en que std::move() pueda arrojar en la biblioteca estándar, pero hay casos. Por ejemplo, si el contenedor usa un asignador con estado, sus hijos también usan este asignador, pero no se moverá a un resultado: esto preferiría obtener una versión construida predeterminada de un asignador (si lo eliminé correctamente). Dado que los asignadores son con estado, esto significa que el objeto no se puede mover y, por lo tanto, la construcción del movimiento falla con una excepción. ¿Por qué este tipo tiene un constructor de movimiento? Bueno, porque podría crearse una instancia con un asignador no con estado, en cuyo caso el movimiento no arrojaría. Además, una vez que nos movemos a las clases definidas por el usuario, no tenemos idea de bajo qué condición podría moverlas.

Answer 3

Otro problema es que no todas las clases realmente se benefician del movimiento, es decir, que solo pueden tener un copiador.

struct DontLikeMoves{ 
    // some data, whatever... 
    DontLikeMoves(DontLikeMoves const& other){ 
    // might throw, who knows! 
    // and this will even get called for rvalues 
    } 
};