Subject: Re: [boost] [variant] compatibility with move-constructible objects
From: Larry Evans (cppljevans_at_[hidden])
Date: 2010-03-26 18:33:32
On 02/22/10 23:06, Zachary Turner wrote:
> I have the following rough sequence of typedefs:
>
> struct empty {};
> typedef std::unique_ptr<foo> foo_ptr;
> typedef std::unique_ptr<bar> bar_ptr;
>
> typedef std::vector<foo_ptr> foo_ptr_vec;
> typedef std::vector<bar_ptr> bar_ptr_vec;
>
> typedef std::variant<empty, foo_ptr_vec, bar_ptr_vec> my_variant;
>
> I then declare an instance of my_variant in a class, and make the class
> moveable and noncopyable.
>
> class my_class
> {
> my_class(const my_class&);
> my_class& my_class(const my_class&);
>
> my_variant v_;
>
> public:
> my_class(my_class&& other)
> : v_(std::move(other.v_))
> {
> }
> };
>
> I cannot get this to compile under MSVC 10 and boost 1.42. In theory I
> don't see why this shouldn't be ok. Even though the objects are not
> copy-constructible due to unique_ptr, they are move constructible. The
> errors are quite long, but you can see it's trying to invoke
> vector::operator= from within the variant code.
>
> Is this just a technical limitation of variant, or a bug?
>
The attached code produces output:
***after my_class default::CTOR:
which=0
***after foo_ptr::CTOR:
fp.get=0x606010
***after push:
fp.get=0
fpv1.at(0).get()=0x606010
***after move:
fpv1.size()=0
fpv2.at(0).get()=0x606010
***after inject:
foo_ptr_vec which=1
fpv2.size()=0
x.project<1>()->at(0).get()=0x606010
Compilation finished at Fri Mar 26 17:25:54
If you're interested, I'll upload to the vault the latest version of
composite_tagged_seq.hpp that was used to produce this.
-regards,
Larry