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: 405
        
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