Re: "moveable data type" in comparison with "r-value reference"
On 21 mar, 20:33, grizl...@yandex.ru ("Grizlyk") wrote:
The state of the source may be unchanged, or it may be radically
different. The only requirement is that the object remain in a self
consistent state (all internal invariants are still intact).
The requirement is theoretically correct, but practically useless one,
because even auto_ptr wrapper has other behaviour.
Note, it is very important for auto_ptr that its state after "move" became
incorrect and user must not have access to auto_ptr during incorrect state,
because else we can not implement desired behaviour of auto memory
substitution.
Observe the implementation of the "pseudo-move constructor" for
auto_ptr in current libstdc++ main line:
auto_ptr(auto_ptr& __a) throw() : _M_ptr(__a.release()) { }
element_type*
release() throw()
{
element_type* __tmp = _M_ptr;
_M_ptr = 0;
return __tmp;
}
After we move from __a it becomes just as if default constructed.
So it is not true that move semantics require the moved-from object to
have incorrect internal state.
Article "apperance of moveable concept" on my pagehttp://grizlyk1.narod.ru/cpp_new#14_1coming soon.
From a client code point of view, choosing move instead of copy means
that you don't care what happens to the state of the source.
Here "copying from non-const source" and "move" are mixed. There are
differences beetwen them. For "move" source state _never_ will be correct or
UB, _always_ will be incorrect.
This _never_ is artificial.
There is no practical requirement for it.
This _never_ implies the above implementation of auto_ptr is wrong.
It is not.
--
Pedro Lamar?o
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]