创建一个不可复制的 STL 迭代器是个好主意吗？
大多数时候，STL 迭代器是可复制构造的，因为一些 STL 算法需要它来提高性能，例如 std::sort。
但是，我一直在开发一个宠物项目来包装 FindXFile API (之前询问过），但问题是不可能围绕此 API 实现可复制的迭代器。查找句柄不能以任何方式复制 - DuplicateHandle 特别禁止将这些类型的句柄传递给它。如果您只是维护对查找句柄的引用计数，那么任何副本的单个增量都会导致所有副本的增量 - 显然这不是副本构造迭代器应该做的事情。
由于我无法满足此处迭代器的传统复制构造要求，是否值得尝试创建“STL 样式”迭代器？一方面，创建一些其他枚举方法将不符合正常的 STL 约定，但另一方面，如果此迭代器的用户稍后尝试 CopyConstruct 它，则遵循 STL 约定将使该迭代器的用户感到困惑。
两害相权取其轻？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不是前向迭代器的输入迭代器是可复制的，但您只能“使用”其中一个副本：递增其中任何一个都会使其他副本无效（取消引用其中一个副本不会使其他副本无效）。这允许将其传递给算法，但算法必须通过单次传递完成。您可以通过检查其要求来判断哪些算法是可以的 - 例如，
copy仅需要一个 InputIterator，而adjacent_find需要一个 ForwardIterator（我发现的第一个）。在我看来，这似乎描述了您的情况。只需复制句柄（或引用句柄的内容），而不重复它。
用户必须明白它只是一个InputIterator，但实际上这没什么大不了的。
istream_iterator是相同的，并且出于相同的原因。凭借 C++11 的后见之明，要求 InputIterators 可移动但不要求它们可复制几乎是有意义的，因为无论如何重复项的使用都是有限的。但这是“有限使用”，而不是“无用”，无论如何，考虑到有多少代码依赖于现有定义，现在从 InputIterator 中删除功能为时已晚。
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
copyrequires only an InputIterator, whereasadjacent_findrequires 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_iteratoris 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.