RE: [boost] iterator_adaptors.hpp/transform_iterator

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.

  -gary-

gary.powell_at_[hidden]

> -----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
> more
> refined than InputIterator (unless you store a cached copy of the value in
> the iterator) because all other iterator categories require a true
> reference
> 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
> wraps.
> 
> 
> -Dave
> 
> ----- 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
> the
> > contents of that one field. A reference not a copy is required in this
> case.
> > (Oh all right, I could return a copy of a pointer to the data, but it
> seems
> > dumb.)
> >
> > If you don't want to support this, I understand but it may mean we
> diverage
> > the code for a while, and that seems a shame.
> >
> >   I'll go check out your proposal...
> >
> >   -gary-
> >
> >
> > To unsubscribe, send email to:
> <mailto:boost-unsubscribe_at_[hidden]>
> >
> >
> > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
> >
> >
> 
> 
> To unsubscribe, send email to: <mailto:boost-unsubscribe_at_[hidden]>
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
>