Modify

Opened 6 years ago

Closed 3 years ago

#5816 closed Bugs (fixed)

any_range requires copyable elements

Reported by: bromeon@… Owned by: neilgroves
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 3 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 3 years ago by neilgroves

  • Status changed from new to 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 Changed 3 years ago by neilgroves

  • Resolution set to fixed
  • Status changed from assigned to closed

Add Comment

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain neilgroves.
The resolution will be deleted. Next status will be 'reopened'.
Author


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

 
Note: See TracTickets for help on using tickets.