Opened 11 years ago

Closed 9 years ago

#5816 closed Bugs (fixed)

any_range requires copyable elements

Reported by: bromeon@… 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 voivoid@…, 9 years ago

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:

any_iterator_interface.hpp
49,51c49,53
<             typedef typename remove_const<
<                 typename remove_reference<Reference>::type
<             >::type reference_as_value_type;
---
>             typedef typename mpl::if_< 
>                 is_trivially_copy_constructible<typename remove_reference<Reference>::type> 
>               , typename remove_const<typename remove_reference<Reference>::type>::type 
>               , Reference 
>             >::type reference_as_value_type;

comment:2 by anonymous, 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 Neil Groves, 9 years ago

Status: newassigned

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 Neil Groves, 9 years ago

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.