Re: [boost] [Range] Range adaptor approach for temporary range lifetime issue

Subject: Re: [boost] [Range] Range adaptor approach for temporary range lifetime issue
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-06-24 04:36:05

On Sat, Jun 23, 2012 at 7:20 PM, Michel Morin <mimomorin_at_[hidden]> wrote:

> Jeffrey Lee Hellrung, Jr. wrote:
> > What I mean is that currently,
> >
> > r | reversed
> >
> > returns a reverse_range<R> which stores its adapted range by reference
> > (i.e., R&).
>
> reverse_range<R> does not store the reference; it stores adapted iterators
> (i.e. a pair of reverse_iterator<range_iterator<R>::type>).
>

Oh, my mistake! That was an implicit assumption based on an incomplete read
of the documentation :( In that case, my suggestion would be more radical
relative to the present implementation.

> What if we introduced a metafunction that dictated what
> > reverse_range<R> should store its adapted range by, either R& (most of
> the
> > time) or R (in the case that the adapted range is a directly or
> indirectly
> > a moved_range/by_value_range).
>
> Do you mean reverse_range<R> stores reverse_forwarder and R
> for the latter case?
>

Yes (I think so).

Now I'm curious: what are the advantages and disadvantages of implementing
reverse_range<R> as a pair of reverse_iterator< R::iterator >'s (I'm being
sloppy here, but based on your above assertion, this is the present
implementation) versus as a wrapper around an R (held by reference or
value) directly? In the latter case, for example, reverse_range<R>::begin
would return reverse_iterator< R::iterator >(boost::end(r)) (where r is the
wrapped range of type R).

- Jeff