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-23 20:09:21

Jeffrey Lee Hellrung, Jr. wrote:
> I think moved and move_forwarder are confusing names as I would think they
> would take a meaning similar to that in N1871/N1781/whatever (i.e.,
> wrapping the adapted range's iterators in move_iterators). Forwarded is
> better, but my suggestion is something along the lines of "by_value" and
> "by_value_if_rv":

I admit that moved and forwarded are confusing names.
I'm OK with any naming that is concise and clear ;)

> But I think the
> important semantic property about this wrapper is that it effectively
> signals the "range adaptor operator|" to adapt *by value*, and the fact
> that we move to achieve this is just consequence (i.e., most of the time,
> we could copy, it would just be less efficient).

Yep, move is just an optimization.

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

Regards,
Michel