From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2001-03-27 18:16:19
I understand your current reasoning, but for VTL to work well, I really
could use the extended iterator concepts that Jeremy wrote about. Until
then, I can test the result type of the function and select the correct
Iterator adaptor, but its going to bug people that for a transform on a
random access container, they can only do forward access.
It makes no sense to link these two concepts.
Again I thank you both for all your work on this.
> -----Original Message-----
> From: David Abrahams [SMTP:abrahams_at_[hidden]]
> Sent: Tuesday, March 27, 2001 3:28 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] iterator_adaptors.hpp/transform_iterator
> Let me try to explain a little more carefully.
> If you are returning values from your function, your iterator cannot be
> refined than InputIterator (unless you store a cached copy of the value in
> the iterator) because all other iterator categories require a true
> be returned when dereferenced
> That's why we have both Transform Iterator and Projection Iterator.
> projection_iterator_generator applies to functions that return references,
> so the result may model a concept as refined as RandomAccessIterator. The
> resulting iterator has the same iterator_category as the Iterator it
> ----- Original Message -----
> From: "Gary Powell" <Gary.Powell_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Tuesday, March 27, 2001 12:34 PM
> Subject: RE: [boost] iterator_adaptors.hpp/transform_iterator
> > As I see it, for VTL, I don't want just value semantics for
> > transform_iterators. Depending on the function I may want a reference
> > returned. (The issue isn't just increment and decrement.)
> > As an example I have used a transform_view to make a container of player
> > data return only a field in the data, then using the iterator, modified
> > contents of that one field. A reference not a copy is required in this
> > (Oh all right, I could return a copy of a pointer to the data, but it
> > dumb.)
> > If you don't want to support this, I understand but it may mean we
> > the code for a while, and that seems a shame.
> > I'll go check out your proposal...
> > -gary-
> > To unsubscribe, send email to:
> > Your use of Yahoo! Groups is subject to
> To unsubscribe, send email to: <mailto:boost-unsubscribe_at_[hidden]>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk