Re: [boost] iterator_adaptors dereference() ?

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-19 08:31:28

----- Original Message -----
From: "Toon Knapen" <toon.knapen_at_[hidden]>

> True. But currently there's only an 'operator*() const' defined in the
> iterator_adaptor which calls the 'dereference() const' on the policy
> class, but both return a reference instead of a const_reference.
>
> To support mutable iterators, I guess non-const versions should be added ?

See footnote 6: http://www.boost.org/libs/utility/iterator_adaptors.htm#6

> >>I'm using a projection_iterator to navigate over a sequence and my
> >>UnaryFunction returns a const reference. This results in a compiler
> >>error (gcc-3.0.3).
> >>
> >
> > It sounds like your function returns T const& but you made the
iterator's
> > reference type plain T&. That's a no-no.
>
> see above.

I don't see anything above that addresses my suggestion.

> BTW, should'nt it be best that a check would be added to
> check if the return_type of the function is equal to the const_reference
> or reference of the iterator_adaptor.

It depends if you want to disable implicit conversions (e.g. Derived->Base).
I don't.

> > Or, perhaps you are returning a U& but you made your function's
result_type
> > U& instead of U. It looks like the projection_iterator assumes you
followed
> > the model of the standard's reference-returning function objects (e.g.
> > http://www.sgi.com/tech/stl/select1st.html)
> >
> >
> >>Particular in the case of the projection_iterator, the 'function' is a
> >>one way function (able to convert the  real content to the iterator's
> >>value_type and not vice-versa, thus the iterator can never be writeable)
> >>
> >
> > That might be a job for transform_iterator. Where does the reference
come
> > from?
>
>
> I use the projection_iterator because it returns a reference instead of
> a value_type (and thus followed the suggestion in the doc)

I was asking where the reference comes from because typical jobs for
Projection Iterators are things like select1st, which returns a
reference/const reference to the first element of a std::pair. Normally if
you don't have an lvalue sitting around to which you can form a reference,
you need transform_iterator. So, I'll ask again, where does the reference
come from?

> >>and thus only a 'dereference() const' is possible returning a
> >>const_reference IMHO ?
> >>
> >
> > There is no const_reference typedef.
> >
> > However, it would make sense for projection_iterator_adaptor to be able
to
> > cope with function objects whose result_type is a reference, at least
when
here I mean a typedef----------------^^^^^^^^^^^
> > partial specialization is available. Would you care to contribute a
simple
> > patch? Most of the work goes into expanding the test suite; aside from
that
> > you just need remove_const< remove_reference< result_type >::type
>::type in
> > the generator to get the value_type.
>
>
> with the above question I'm trying to grasp what changes would be
involved.

>>>> What is the result_type of your function object? <<<<