On 05-Oct-2015 12:33, Shachar Shemesh wrote:
On 05/10/15 10:49, Dmitry Olshansky wrote:
Yes and no, if your type is movable in C++ you have to have a T.init
equivalent to leave something behind after move (oops!).
No, under C++ you can choose whether it makes sense for your type to be
movable or not.
IF you need a movable type. Most types these days ought to be movable to
be fast. So it's OOPS after all. e.g. vector<T> is movable hence it has
T.init.
*Everything non-trivial* in STL now has T.init, including the unique_ptr
and shared_ptr.
The T.init is hidden somewhat:
auto a = unique_ptr<int>(new int);
auto b = move(a);
// now a is unique_ptr<int>.init that is null
Same goes for locks, threads and whatnot.
My point is: if it can move, it has T.init.
Copyable types that are not movable are a minority IMO.
Non-movable were described in the snipped part of my message.
No oops at all.
C++ does not make any attempt to protect you from your own incompetence.
Sadly it goes to great lengths to prove your own incompetence.
Eventually it does, but that is OT.
Within that assumption (which some people accept as reasonable and
others don't), C++ does the right thing.
If I got you right you seem to imply that types that are copyable but
not movable are a good thing. I humbly disagree.
--
Dmitry Olshansky
