Understood. I was just wondering if the two issues you raised about using distance hinted at a possible better solution.
If one needs to solve this for iterators that are not random access I see two approaches: 1. Augment your container structure that produces the initial range to track the distance between the range you are building. This might or might not make any sense at all depending on the container and the requirements upon the sub-range.
2. Augment/wrap the iterators so that the wrapped iterator satisfies more requirements than a ForwardIterator by being able to calculate the distance in O(1). This can be achieved by maintaining an additional index. The wrapped iterator would still not model the RandomAccessIterator Concept since it would not need to provide O(1) advance etc.
Each of these is probably too much additional work until a concrete use-case presents itself. I don't see why any of that is necessary. Take a look at the 'taken' [1] and 'dropped' [2] range adaptors from the proposed extensions to Boost.Range.
Using them, the sub-range starting at index 'start' and being of length 'len' is simply: original_range | dropped(start) | taken(len) These range adaptors work on SinglePassRanges. This is what I meant by a 'hand-crafted' solution, though it won't be hand-crafted after these extensions are accepted into Boost.Range. (How is the review of these extensions coming along, by the way?) Regards, Nate [1] http://dl.dropbox.com/u/1682460/git/OvenToBoost/libs/range/doc/html/range_ex... [2] http://dl.dropbox.com/u/1682460/git/OvenToBoost/libs/range/doc/html/range_ex...