Действительно ли это - хорошая идея создать итератор STL, который noncopyable?
Большую часть времени итераторами STL является CopyConstructable, потому что несколько алгоритмов STL требуют, чтобы это улучшило производительность, такой как std::sort.
Однако я работал над любимым проектом перенести FindXFile API (ранее спрошенный о), но проблема, невозможно реализовать copyable итератор вокруг этого API. Дескриптор находки не может быть дублирован каким-либо образом- DuplicateHandle конкретно запрещает передачу этих типов дескрипторов к нему. И если Вы просто поддерживаете подсчет ссылок к дескриптору находки, затем единственный инкремент какими-либо результатами копии в инкременте всех копий - ясно, который не является тем, что созданный итератор копии, как предполагается, делает.
Так как я не могу удовлетворить традиционную копию конструируемое требование для итераторов здесь, даже стоит попытаться создать "итератор" стиля STL? С одной стороны создание некоторого другого метода перечисления собирается не попасть в нормальные конвенции STL, но на другом, после STL, конвенции собираются смутить пользователей этого итератора, если они пробуют к CopyConstruct его позже.
Который является меньшим из двух зла?
1 ответ
Итератор ввода, который не является прямым итератором, можно копировать, но вы можете «использовать» только одну из копий: увеличение одной из них делает другие недействительными ( разыменование одного из них не делает другие недействительными). Это позволяет передавать его алгоритмам, но алгоритм должен выполняться за один проход. Вы можете определить, какие алгоритмы подходят, проверив их требования - например, copy требует только InputIterator, тогда как neighbour_find требует ForwardIterator (первый, который я нашел).
Мне кажется, это описывает вашу ситуацию. Просто скопируйте дескриптор (или что-то, что пересчитывает дескриптор), не дублируя его.
Пользователь должен понимать, что это всего лишь InputIterator, но на практике это не имеет большого значения. istream_iterator такой же, и по той же причине.
Учитывая преимущество C ++ 11 задним числом, почти имело бы смысл требовать, чтобы InputIterators были перемещаемыми, но не требовали, чтобы они были копируемыми, поскольку дубликаты в любом случае имеют ограниченное использование. Но это «ограниченное использование», а не «бесполезность», и в любом случае уже слишком поздно удалять функциональность из InputIterator, учитывая, насколько код зависит от существующего определения.