Является ли хорошей идеей создать итератор STL, который нельзя скопировать?

Question

Большую часть времени итераторы STL являются CopyConstructable, поскольку для повышения производительности требуется несколько алгоритмов STL, например std::sort.

Тем не менее, я работал над любимым проектом, чтобы обернуть API FindXFile ( ранее спрашивал о ), но проблема в том, что невозможно реализовать копируемый итератор вокруг этого API. Дескриптор поиска нельзя дублировать никакими средствами - DuplicateHandle специально запрещает передавать ему дескрипторы этих типов. И если вы просто сохраняете счетчик ссылок на дескриптор поиска, то одно приращение любой копии приводит к приращению всех копий - очевидно, это не то, что должен делать созданный копией итератор.

Поскольку я не могу удовлетворить традиционное требование создания копии для итераторов, стоит ли даже пытаться создать итератор в стиле STL? С одной стороны, создание какого-либо другого метода перечисления не попадет в обычные соглашения STL, но с другой стороны, следующие соглашения STL приведут в замешательство пользователей этого итератора, если они попытаются скопировать его позже.

Какое из двух зол меньше?

Answer 1

Входной итератор, который не является прямым итератором, можно копировать, но вы можете «использовать» только одну из копий: увеличение одной из них делает недействительными другие (разыменование одной из них не делает недействительными другие). Это позволяет передавать его в алгоритмы, но алгоритм должен завершаться за один проход. Вы можете узнать, какие алгоритмы в порядке, проверив их требования - например, copy требует только InputIterator, тогда как adjacent_find требует ForwardIterator (первый, который я нашел).

Мне кажется, что это описывает вашу ситуацию. Просто скопируйте дескриптор (или что-то, что пересчитывает дескриптор), не дублируя его.

Пользователь должен понимать, что это всего лишь InputIterator, но на практике это не имеет большого значения. istream_iterator то же самое, и по той же причине.

Оглядываясь назад, можно сказать, что с учетом C ++ 11 почти имело бы смысл требовать, чтобы InputIterator был перемещаемым, а не копировать его, поскольку дубликаты в любом случае имеют ограниченное использование. Но это «ограниченное использование», а не «бесполезное», и в любом случае уже слишком поздно, чтобы удалить функциональность из InputIterator, учитывая, сколько кода опирается на существующее определение.