Question

Most of the time, STL iterators are CopyConstructable, because several STL algorithms require this to improve performance, such as std::sort.

However, I’ve been working on a pet project to wrap the FindXFile API (previously asked about), but the problem is it’s impossible to implement a copyable iterator around this API. A find handle cannot be duplicated by any means — DuplicateHandle specifically forbids passing these types of handles to it. And if you just maintain a reference count to the find handle, then a single increment by any copy results in an increment of all copies — clearly that is not what a copy constructed iterator is supposed to do.

Since I can’t satisfy the traditional copy constructible requirement for iterators here, is it even worth trying to create an “STL style” iterator? On one hand, creating some other enumeration method is going to not fall into normal STL conventions, but on the other, following STL conventions are going to confuse users of this iterator if they try to CopyConstruct it later.

Which is the lesser of two evils?

Answer 1

An input iterator which is not a forward iterator is copyable, but you can only “use” one of the copies: incrementing any of them invalidates the others (dereferencing one of them does not invalidate the others). This allows it to be passed to algorithms, but the algorithm must complete with a single pass. You can tell which algorithms are OK by checking their requirements – for example copy requires only an InputIterator, whereas adjacent_find requires a ForwardIterator (first one I found).

It sounds to me as though this describes your situation. Just copy the handle (or something which refcounts the handle), without duplicating it.

The user has to understand that it’s only an InputIterator, but in practice this isn’t a big deal. istream_iterator is the same, and for the same reason.

With the benefit of C++11 hindsight, it would almost have made sense to require InputIterators to be movable but not to require them to be copyable, since duplicates have limited use anyway. But that’s “limited use”, not “no use”, and anyway it’s too late now to remove functionality from InputIterator, considering how much code relies on the existing definition.