|
Boost : |
From: John E. Potter (jpotter_at_[hidden])
Date: 2001-08-10 23:11:28
On Fri, 10 Aug 2001, Douglas Gregor wrote:
> The code posted is more along the lines of an iterator adaptor. Consider the
> transform_iterator_adaptor from the iterator adaptors library, but with a
> function object that has side effects. operator* must be stable, so we have
> to cache the value. The some_input_iterator code posted is a skeletal
> description of how one would make transform_iterator_adaptor conform to the
> input iterator concept regardless of any side effects due to calling the
> function.
Sorry, I missed the whole point because of the attempt to provide some
unrequired meaning for operator==. The shared cache is not required.
The point that I could not see is that operator* returns the cache
and operator++ calls the function. Implementing an input_iterator is
not difficult, but it may be made difficult. :)
> I think we all agree on stable operator*.
I think that is a dangerous assumption. There may even be an open
issue in the LWG.
I have refined my views on operator==. Thanks for the discussion.
The problems are realy not important because for input_iterators,
"In the end there can only be one". <g>
John
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk