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-25 12:41:59

On Mon, Jun 25, 2012 at 4:45 AM, Michel Morin <mimomorin_at_[hidden]> wrote:

> Jeffrey Lee Hellrung, Jr. wrote:
> > On Sun, Jun 24, 2012 at 2:51 AM, Michel Morin <mimomorin_at_[hidden]>
> wrote:
> >
> >> Jeffrey Lee Hellrung, Jr. wrote:
> >> >> > 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).
> >>
> >> Then, compared to the current implementation of reverse_range,
> >> the implementations of your reverse_range and my moved_range
> >> are essentially the same, right?
> >>
> >
> > More or less, modulo storage rules. Your moved_range always stores the
> > underlying range by value; my reverse_range would store by value or by
> > reference depending on some type property of the underlying range.
>
> OK, now I can answer your original question:
>
> > Question: Why have the operator| on the moved_range return another
> > moved_range, accumulating the adaptors explicitly in a Fusion sequence?
>
> Accumulating the adaptors is necessary, because I didn't change
> the implementation of the existing Boost.Range's range adaptors.
>
> > Couldn't we just return the usual range adaptor types, with special
> > metafunction logic to switch to by-value storage (rather than the default
> > reference storage) of the adapted range when its a moved_range or an
> > adaptation of a moved_range?
>
> The lifetime problem can be solved by your range adaptors.
> I chose to implement moved_range, just because adding moved_range
> is easier for me than changing each range adaptor implementation.
> Yeah, I'm lazy :-)
>

Right, just making sure I didn't miss something.

There's definitely some value in preserving the present
structure/implementation/whatever of the Boost.Range adaptors as much as
possible, so I don't think it's laziness on your part...entirely :)

- Jeff