Re: [boost] [range] Question about adapted range safety given C++11 auto

Subject: Re: [boost] [range] Question about adapted range safety given C++11 auto
From: Eric Niebler (eric_at_[hidden])
Date: 2012-04-22 13:21:47

On 4/22/2012 6:21 AM, Beman Dawes wrote:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3350.html
> claims:
> 
> "Boost's range library focuses on defining a set of Range concepts 
> that allow Containers to be Ranges. Because Containers are 
> heavy-weight, this forces Boost to use references for all of their 
> uses of Ranges, including Ranges that are captured by Range
> Adapters. This worked fine in C++98, where users couldn't name the
> types of the Range Adapters in order to declare local variables, but
> with C++11's auto keyword, users can now save adapted ranges. Since
> Boost's adapted ranges capture references to their arguments, which
> can be temporaries, this is no longer a safe design."
> 
> Is this claim correct?

I imagine so. Expression template libraries (including std::valarray!)
have the same problem.

> If so, what's the real-world impact?

On the user? "Don't do that." On the library design? Boost.Range *could*
detect when an rvalue range is being adapted and steal its guts instead
of holding it by reference. This could get expensive if move causes a
copy for some heavy range type.

My gut is telling me not to do that, though. It's a range *adaptor*. The
range being adapted must exist at least as long as the adaptor. A better
design (IMHO) would be to detect the internal chained adaptors (what
gets returned from transform or filter), and steal *their* guts ... but
never try to move the underlying range being adapted.

Then the question is only about corner cases like if the predicate of a
filter adaptor is heavy and doesn't have a nothrow move c'tor, but I
tend to doubt that comes up often.

My $.02,

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com