Boost C++ Libraries: Ticket #11132: Boost.Variant's boost::recursive_wrapper missing noexcept specifier on move constructor

summary changed

peterhuene@… — Fri, 20 Mar 2015 19:49:50 GMT

summary Boost.Variant's boost::recursive_wrapper missing noexcept specified on move constructor → Boost.Variant's boost::recursive_wrapper missing noexcept specifier on move constructor

peterhuene@… — Sat, 21 Mar 2015 19:28:18 GMT

Actually, upon more thought, there's no reason to use shared_ptr<T> here at all.

boost::recursive_wrapper(boost::recursive_wrapper&& operand) noexcept

This simply needs to take ownership of operand's _p so that operand doesn't delete it. No shared_ptr required (silly suggestion).

Steven Watanabe — Sat, 21 Mar 2015 19:55:45 GMT

I'm pretty sure that we discussed this implementation of move construction on the developer's list a couple of years ago, and decided that it was incorrect, because it introduces an additional moved-from state.

peterhuene@… — Sun, 22 Mar 2015 01:49:37 GMT

Is invoking T's move constructor when the wrapper is moved really more important than maintaining move semantics for vector<recursive_variant_> and, by extension, the entire variant type?

I get that the wrapper is supposed to be as transparent as possible to the user of the recursive variant (i.e. T's move constructor would normally be invoked on move), but, in my opinion, the intent of move semantics is still being adhered to if _p is moved instead of a new T allocated and then moved into.

To put it another way: I think forcing copy semantics for recursive variants with sequence containers (for the sake of complete wrapper transparency?) to be unreasonably burdensome for users expecting their variants to be efficiently movable.

owner, status changed

Antony Polukhin — Mon, 22 Jun 2015 19:59:39 GMT

owner changed from ebf to Antony Polukhin
status new → assigned

This issue has been discussed a lot. After a very long discussion it was decided to leave recursive_wrapper as is.

Personaly I dislike the existing approach, but agree that it must stay as is.

The only way that I could help you, is to show some possible workarounds. Here's a workaround for std::vectors that support incomplete/forward declared types (fastest possible solution):

#include <boost/variant.hpp>
#include <vector>
using namespace std;
using namespace boost;
struct foo
{
	foo() = default;
	foo(foo&&) noexcept = default;
	foo(foo const&) = delete;
};
struct variant_type: boost::variant<foo, vector<variant_type> > {
    typedef boost::variant<foo, vector<variant_type> > base_t;
    variant_type() = default;
    template <class T>
    variant_type(T&& v)
        : base_t(std::forward<T>(v))
    {}
};
int main() {
	vector<variant_type> value;
	value.emplace_back();
	variant_type other = std::move(value);
}

This example must work on popular STL implementations.

status changed; resolution set

Antony Polukhin — Wed, 18 Jan 2017 19:48:30 GMT

status assigned → closed
resolution → wontfix