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