[move] unique_ptr: problems with move-assign constructor when used with base/derived classes in C++03
Hi, There is a problem with move-assignment constructor in boost::movelib::unique_ptr when used with a pair of base/derived classes in C++98/03 mode [1] (uncomment the code to see the compiler error). Is it a known issue? Or a limitation of the emulation? I discovered the issue when I wanted to use boost::movelib::make_shared in an answer to a question on StackOverflow [2], i.e. return boost::movelib::make_shared<Derived>(); Where the return value is boost::movelib::unique_ptr<Base>, but unfortunately because of this issue, in C++03 we need to use: return unique_ptr<Base> x(new Derived()); I can create a ticket if that is desired. Nevertheles, thanks for boost::movelib::unique_ptr anyway! BTW, note how the appearance of boost::movelib::unique_ptr makes the most voted answer on the question [3] invalid. This is where my answer comes in. Best regards, Adam Romanek [1] http://melpon.org/wandbox/permlink/8Rvk2g7LJ0Ey0BQL [2] http://stackoverflow.com/a/28193068/1776942 [3] http://stackoverflow.com/q/2953530/1776942
El 05/03/2015 a las 12:17, Adam Romanek escribió:
Hi,
There is a problem with move-assignment constructor in boost::movelib::unique_ptr when used with a pair of base/derived classes in C++98/03 mode [1] (uncomment the code to see the compiler error).
Is it a known issue? Or a limitation of the emulation?
It's a limitation because the c++03 standard requires a viable copy constructor for copy initialization expressions: T t = T() and unique_ptr has no copy constructor. Some non-conforming compilers (like MSVC 7.1) don't require it, but the standard is clear. You can use use direct initialization to get the same effect: unique_ptr<Base> z(boost::move(x)); Best, Ion
participants (2)
-
Adam Romanek -
Ion Gaztañaga