Subject: Re: [boost] [Range] Range adaptor approach for temporary range lifetime issue
From: Michel Morin (mimomorin_at_[hidden])
Date: 2012-07-06 07:31:32
Neil Groves wrote:
> If we are pushing the laziness to the extreme whereby the begin()/end()
> calls create the iterators we are also changing the exception semantics be
> delaying throws. I therefore tend to think that we would be better having
> lazy range adaption by the adaptors creating a class convertible to a range
> that captures and hence triggers the adaptor evaluation via implicit
> conversion. I proposed this on the list a few weeks ago. I see no reason to
> break backward compatibility by loosening the performance guarantees of
Ah, now I understand what you're trying to do.
You're controlling the timing of range adaptor invocation
for lazy implementation, right?
For example, in the following code with your proposed implementation,
reversed_range<...> rng = xxx | reversed;
reversed range adaptor is invoked when lazy adaptor `xxx | reversed`
is implicitly converted to reversed_range<xxx> `rng`,
instead of when begin/end to `rng` is called.
This solution does not work for auto-typed variables and function templates,
since no implicit conversion is applied in those cases.
So I think it would be better to provide a member function for
explicit invocation of range adaptors
auto rng = (xxx | reversed).eval();
or a range adaptor
auto rng = xxx | reversed | eval;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk