On Sat, Jun 23, 2012 at 5:09 PM, Michel Morin <mimomorin@gmail.com> 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