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

Subject: Re: [boost] [Range] Range adaptor approach for temporary range lifetime issue
From: Michel Morin (mimomorin_at_[hidden])
Date: 2012-06-25 07:45:47

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

Regards,
Michel