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:
> "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.
-- Eric Niebler BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk