From: David White (dave_at_[hidden])
Date: 2002-05-17 05:05:12
On Fri, 2002-05-17 at 17:27, Victor A. Wagner, Jr. wrote:
> That's very nice
> ... unfortunately, it doesn't "drop in" to any of the algorithms which only
> will use ++iter and a != test for "end".
> Can you think of any way to "wrap" it so that we could call copy, or any of
> the other algorithms with an "iterator" which somehow does your distance_n
> when ++ is "applied" ??
> This would allow (well, at least me) to write things like:
> copy(stride_iterator(cont.begin(), cont.end(), 5), cont.end(),
> someoutputiterator); // copy every 5th element
> I suppose the "ending condition" wouldn't actually be necessary if the
> operator !=() were designed to return false iff it had become == the
> "cont.end()" provided at construction time.
Well, it "drops in" to the STL algorithms equally well to the existing
distance function. An alternative though, which allows more interaction
with STL algorithms is to have an iterator adapter that I call
iterator_n, it takes an index as a parameter, along with the iterator,
it moves the index every time the iterator is moved, and is defined to
compare two iterators as equal if the underlying iterators are equal, or
if the indexes are equal.
would have the same functionality as the distance_n provided. (The index
parameter could be defaulted to 0, and so would be unnecessary for the
first one). Further, one could do the following:
to copy at most 5 elements to buffer. I would find something like this
fairly useful in a number of areas.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk