Is it a good idea to create an STL iterator which is noncopyable?
Posted
by BillyONeal
on Stack Overflow
See other posts from Stack Overflow
or by BillyONeal
Published on 2010-04-02T18:01:18Z
Indexed on
2010/04/02
18:03 UTC
Read the original article
Hit count: 363
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 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?
© Stack Overflow or respective owner