On 11/7/2013 6:27 PM, Nathan Ridge wrote:
The trick, of course, will be keeping intermediate temporary ranges alive long enough to avoid lifetime issues when we chain adaptors and assign the result to a local variable. I think a range library that's sensitive to the value category of range objects and makes copies of rvalue ranges would solve this problem. Thoughts?
This is definitely something that needs to be added. The challenge is merely finding sufficient time to do so.
Jeffrey Yaskin posted a candidate design, implemented for filter_iterator, here: https://svn.boost.org/trac/boost/ticket/7630
What do you think about this design?
It's a step in the right direction, but it still is essentially an iterator_range of filter_iterators. Each filter_iterator is fat; they both store a copy of the filter predicate. Rather, filter_range should store the predicate, and the iterators returned from filter_range should just hold a pointer to the range. That's what I'm suggesting. And to answer Neil's objection, it necessarily means the iterators can't outlive the range, but IMO it's wrong to assume otherwise. Nobody expects a vector iterator to outlive the vector, after all. It will most certainly be a breaking change, which is why I suggest we ship a C++11 range library in parallel with the existing C++98 one. -- Eric Niebler Boost.org http://www.boost.org