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-23 20:23:02

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

> Jeffrey Lee Hellrung, Jr. wrote:
>
[...]

> > Question: Why have the operator| on the moved_range return another
> > moved_range, accumulating the adaptors explicitly in a Fusion sequence?
>
> I don't fully understand the following
>
> > 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?
>
> So my answer might not take your point..., but let me try.
>
> * At each pipe operator, the container should be moved.
> * Iterators might be invalidated by move.
>
> So all the range adaptors should be applied after (or at) the last pipe
> operator. I did this by explicitly accumulating the range adaptors.
>

What I mean is that currently,

r | reversed

returns a reverse_range<R> which stores its adapted range by reference
(i.e., R&). 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). Then moved_range ultimately becomes some
thin trivial wrapper around its adapted range only meant to induce
overriding the usual by-reference storage inside adaptors, and all the same
operator|'s should work as before.

Does that make sense?

- Jeff