Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk