Question

I know std::queue::pop() returns void. For two reasons:

1. exception safety: something might throw after removing the element
2. to be able to return the value by reference

Fine.

Now if I understand the new C++11 move semantics correctly, the second is no longer a valid argument.

So… the only thing preventing std::queue to have a pop-like function returning the value lies in the possibility that the move constructor throws?

I have a hard time thinking of situations where such a move constructor would throw. Who knows of an example?

I guess the same goes for 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() and what not.

Answer 1

Using clever SFINAE techniques it would indeed be possible to have an atomic non-throwing pop_and_move() for just datatypes that implement no-throwing move or no-throwing copy.

There is even a noexcept() construct available to see if something might throw.

One of the new concepts in C++11 in particular that extends SFINAE is that if the body doesn’t compile the function doesn’t exist. Thus one could implement based on noexcept().

I would say for backward compatibility the function would need a new name, which therefore allows it to co-exist with the existing functionality of calling them separately, not breaking containers of types that do not have the semantics to allow it.