Modify

Opened 6 years ago

Closed 4 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.

Attachments (0)

Change History (4)

comment:1 Changed 4 years ago by voivoid@…

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 Changed 4 years ago by anonymous

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 Changed 4 years ago by Neil Groves

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 Changed 4 years ago by Neil Groves

Resolution: fixed
Status: assignedclosed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Neil Groves.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.