Re: [boost] [Range] Range adaptor approach for temporary range lifetime issue

Subject: Re: [boost] [Range] Range adaptor approach for temporary range lifetime issue
From: Neil Groves (neil_at_[hidden])
Date: 2012-06-25 08:06:27

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 :-)

I understand the rationale entirely and normally this is something I 
would push for. In this case I believe we should be able to iterate upon 
your original solution and take advantage of building some optimizations 
into the range adaptors. I think we can then achieve a zero-cost under 
normal conditions implementation with opt-in explicit moving. I'm 
hacking up something to opt-in once and have the opt-in continue 
left-wise through the application of the | operator.

>
> Regards,
> Michel
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

I think this is merely a small iteration to your original idea, but it 
seems to better separate the design concerns which is motivation enough 
to make the bigger change.

Since you are ahead of me, in terms of the amount of work you have done 
on this, do you foresee any issue with my slight changes?

Thanks,
Neil Groves