> I also realized that you made the copy constructors and copy assignment
> operators private, thereby prohibiting copying. Why? The footprints of the
> classes are small, so copying should be cheap (and the implementation
> straightforward), so why preventing it?

I'm copy editing XSTLv1 (http://extendedstl.com/) right at the minute, and found the bit of text I wanted to quote (even though it's bad taste to quote oneself <g>) from Chapter 19, section 19.3.2:

However, the copy constructor and copy assignment operator have been proscribed. Why? The reason is that readdir_sequence, just like glob_sequence (and pretty much any other file system enumeration API), provides only a snapshot of the system at a given point in time. Disallowing copy semantics prevents the user from easily forgetting this fact.

Tip: Consider proscribing operations from your types for conveying information on appropriate use, as well as for classic robustness and correctness reasons, particularly for collection types that provide snapshots of their underlying collections.

That's why enumerator_sequence *must* not provide these operations. I guess I made collection_sequence the same for no better reason than consistency, but if I think about it, I can certainly argue that the same reasoning *should* apply to collection_sequence (although volatile collections are _much_ more rare than non-repeatable enumerators.)