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-24 18:08:40

On 24 Jun 2012, at 14:18, Michel Morin wrote:

> Neil Groves wrote:
>> As a general idiom the use of lazily adapting upon the invocation of
>> begin/end would mix two responsibilities. If one considers the complications
>> involved with managing functor and predicate state being delayed until the
>> invocation of begin/end it appears to be a considerably more complex
>> solution. I do not perceive a compensating advantage for this approach. Of
>> course, I may well be missing the advantage and invite correction.
> 
> But the lazy adaption is necessary to resolve the lifetime problem:
> 
> * To resolve the lifetime problem, each pipe operator
> should move a temporary container.
> * Since moving a container might invalidate iterators,
> each range adaptors should be applied to the last moved container
> (i.e. the moved container which is moved by the last pipe operator).
> * We cannot distinguish the last pipe operator from other pipe operators.
> 
> So the only feasible timing for applying range adaptors is when
> begin/end is (directly or indirectly) called.
> 

I see, I suspected I was missing the advantage. I currently do not have a better proposal and this does solve the initial problem, but at what cost? Currently the impact of using the range syntax is close to zero, sometimes in fact better than zero. Is it not possible to make the move operation explicit and the don't move implicit?

I have not refined this idea, but intend to experiment in the next couple of days. I am wondering if we couldn't tag certain source ranges as requiring move semantics and propagate this via template tags through the pipe operators.

The return-type of the pipe operator could be altered to be something other than the type the caller wishes to use and have an implicit conversion operation. The implicit conversion could perform the adaption, this would leave begin()/end() with identical performance in client code.

What about returning a different range type that is implicitly convertible to the range type, we could then adapt during conversion. The pipe operators could operate upon the specially tagged types as appropriate.

I certainly wish to explore the solution space a little more before concluding that we have exhausted the solution space.

> 
> Regards,
> Michel
> 

I'll let you know how I get on with this idea in the next couple of days.

Thanks for all of your input. It has been really interesting.

Regards,
Neil Groves