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: