Opened 11 years ago
Closed 9 years ago
#5816 closed Bugs (fixed)
any_range requires copyable elements
Reported by: | Owned by: | Neil Groves | |
---|---|---|---|
Milestone: | To Be Determined | Component: | range |
Version: | Boost 1.47.0 | Severity: | Problem |
Keywords: | Cc: |
Description
boost::any_range attempts to copy container elements even if the Reference template parameter is a reference. This behavior prevents the use of noncopyable element types and is inconsistent with boost::sub_range and boost::iterator_range.
Short code example that doesn't compile (unless private: is commented out):
#include <boost/range/concepts.hpp> // because any_range.hpp doesn't compile alone #include <boost/range/any_range.hpp> #include <vector> // X is movable, but non-copyable class X { public: X() {} X(X&&) {} void operator= (X&&) {} private: X(const X&); void operator= (const X&); }; int main() { std::vector<X> v; boost::any_range<X, boost::random_access_traversal_tag, X&, std::ptrdiff_t> range2 = v; }
The problem might be in line 429 of any_iterator_wrapper.hpp, where reference_as_value_type is used for the Reference template parameter of the underlying any_random_access_iterator_wrapper.
Change History (4)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
I also encountered this problem recently. It prevents me from using boost::any_range as an object interface abstraction, since i don't want the values copied (i want to expose iterators to Base, and supply a container of Derived objects in the implementation).
I do not see any good reason to require copying when all any_range is is an abstract view into the source range. That elements aren't going to be copied should be made into a guarantee.
This is a 2 year old bug, is it possible that it can be fixed soon?
comment:3 by , 9 years ago
Status: | new → assigned |
---|
Yes it will be fixed soon. I've got a bunch more time than I have and I'm trying hard to catch up.
comment:4 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
This problem also prevents a use of abstract class pointers. Any chances this is going to be fixed?
I wonder if the problem could be solved with something like this: