仅移动输入和输出迭代器

Question

Concerning InputIterator / OutputIterator -s is it consistent to modify their semantics to be move-only? Surely I mean only newly-created custom iterators, not STL ones.

Notes to semantic requirements to ++i and ++r expressions for input and output iterators correspondingly says:

Postcondition: Any copies of the previous value of i are no longer required to be either dereferenceable or to be in the domain of == .

After this operation r is not required to be incrementable and any copies of the previous value of r are no longer required to be dereferenceable or incrementable.

I think it is safer to prohibit possibility to have a copies of input/output iterators in most cases, but never heard such advice. Is it bad idea?

Answer 1

In C++20, the new iterators concepts input_iterator and output_iterator do not require to be copyable. The algorithms in the ranges namespace, as well as the view adapters support move only iterators too.

The new view ranges::istream_view returns move-only iterator for increased safety. Finally the new C++20 view concept does itself not require copyability which allows its own state to be move only.

It is still possible to create copyable input_iterator and output_iterator that are not copyable but I would advise not to.

forward_iterator s are, of course, still required to be copyable . Sentinels also require to be copyable

You can read ore about the design in the following papers

• Movability of Single-pass Iterators
• Move-only views
• Ranges adaptors for non-copyable iterators

Answer 2

Input/OutputIterators must first satisfy the Iterator requirement. And that requirement say, from C++14, [iterator.iterators], p2:

A type X satisfies the Iterator requirements if:

• X satisfies the CopyConstructible , CopyAssignable , and Destructible requirements (17.6.3.1)

So no, they cannot be move-only.

Answer 3

That is probably not a good idea. Iterator objects are usually designed to be lightweight and are passed around by value in order to be efficient. And many of the C++ standard library containers use iterators passed by value. Disabling the copy constructors does not seem like a good idea at all to me.

For example see http://www.cplusplus.com/reference/vector/vector/vector/ the vector constructor accepts the input iterator by value.

And see http://www.cplusplus.com/reference/algorithm/copy/ for an example of a C++ standard library container that accepts an output iterator by value