On Mon, Jun 25, 2012 at 4:45 AM, Michel Morin <mimomorin@gmail.com> wrote:
Jeffrey Lee Hellrung, Jr. wrote:
On Sun, Jun 24, 2012 at 2:51 AM, Michel Morin <mimomorin@gmail.com> 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 :-)
Right, just making sure I didn't miss something. There's definitely some value in preserving the present structure/implementation/whatever of the Boost.Range adaptors as much as possible, so I don't think it's laziness on your part...entirely :) - Jeff