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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk