Re: [boost] more problem with functional + projection_iterator

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-10-06 14:04:36

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>

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

seems to me we can handle this one better:

// pseudocode
boost::add_reference<boost::add_const<result_type>::type >::type
operator*()
{
  typedef boost::add_reference<result_type> ref;
  if (0)
  {
    ref x(f(*iterator.base())); // if f returns by value, binds a temp to a
non-const ref
  }
  return f(*iterator.base());
}

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

does any of this require "type unwinding?". I don't think it requires more
than ref/const_ref detection.

-Dave

===================================================
  David Abrahams, C++ library designer for hire
 resume: http://users.rcn.com/abrahams/resume.html

        C++ Booster (http://www.boost.org)
          email: david.abrahams_at_[hidden]
===================================================