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