CODEWITHSUNDEEP
c++c++11iteratorstdmove
Max Beikirch
Max Beikirch

Reputation: 2143

std::move on two deques - input vs output iterators

take a look at the following code:

#include <algorithm>
#include <deque>
#include <iostream>

using namespace std;

int main()
{
  deque<int> in {1,2,3};
  deque<int> out;
  // line in question
  move(in.begin(), in.end(), out.begin());
  for(auto i : out)
    cout << i << endl;

  return 0;
}

This will not move anything. Looking at the example here, one must write the line in question like this:

move(in.begin(), in.end(), std::back_inserter(out));

This makes sense in a way, as std::move expects its first two arguments to be InputInterators (which is satisfied here) and the third one to be an OutputIterator (which out.begin() is not).

What does actually happen if the original code is executed and move is passed an iterator that is not an OutputIterator? Why does C++'s type-safety not work here? And why is the construction of an output-iterator delegated to an external function, i.e. why does out.backInserter() not exist?

Upvotes: 1

Views: 160

Answers (1)

Mike Seymour
Mike Seymour

Reputation: 254461

The original code tries to dereference and increment out.begin(). Since out is empty, that's a past-the-end iterator, and it can't be dereferenced or incremented. Doing so gives undefined behaviour.

std::move expects [...] the third one to be an OutputIterator (which out.begin() is not).

Yes it is. Specifically, it's a mutable random access iterator, which supports all the operations required of an output iterator, and more.

What does actually happen if the original code is executed and move is passed an iterator that is not an OutputIterator?

That would cause a compile error if the iterator didn't support the operations required of an output iterator needed by the function; or undefined behaviour if the operations existed but did something other than that required of an output iterator.

Why does C++'s type-safety not work here?

Because the type is correct. The incorrect runtime state (being a past-the-end iterator, not the start of a sequence with at least as many elements as the input range) can't be detected through the static type system.

why does out.backInserter() not exist?

That would have to be written separately for all sequence containers: both the standard ones, and any others you might define yourself. The generic function only has to be implemented once, in the standard library, to be usable for any container that supports push_back.

Upvotes: 6

Related Questions