Re: [boost] iterator_adaptors dereference() ?

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2002-01-19 04:59:42

David Abrahams wrote:

> ----- Original Message -----
> From: "Toon Knapen" <toon.knapen_at_[hidden]>
> 
> 
>>Should'nt the dereference() in the policies return a const_reference
>>instead of a reference ?
>>
> 
> How would you build a mutable iterator with that?

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 ?

> 
>>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. 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.

> 
> 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)

> 
> 
>>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
> 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.

(sorry for my very late reply)