Re: [boost] [variant] compatibility with move-constructible objects

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