Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-10-06 11:10:56


From: "David Abrahams" <david.abrahams_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
>
> > I have a function that I want to use with projection_iterator. It has to
> > return a reference - this is a projection_iterator requirement.
>
> <snip>
>
> > Bottom line, make_projection_iterator should handle value_type (optional
> and
> > dangerous - for compatibility only; the function object may indeed
return
> by
> > value), value_type &, and value_type const & as possible result_types,
and
> > produce a const/non-const iterator accordingly.
>
> I'm having trouble reconciling your two statements. Are you saying that
> make_projection_iterator should get value_type from
> add_reference<result_type> under the assumption that result_type may not
be
> the real result type?

What I'm trying to say is that make_projection_iterator should (assuming a
conforming compiler):

* handle the case where F::result_type == T const & by creating a const
projection iterator with value_type == T.

* handle the case where F::result_type == T & by creating a non-const
projection iterator with value_type == T.

* do whatever you decide it should do when F::result_type is not a
reference; perhaps assume a "result_type const &" return to allow
select1st/select2nd to work. I'd personally make that an error to avoid
dangling references.

The problem, of course, is how to achieve this without partial
specialization.

--
Peter Dimov
Multi Media Ltd.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk