Mathias Gaunard wrote:
On 08/20/2011 06:09 PM, Julian Gonggrijp wrote:
UNDERLYING_TYPE(T) represents a type which is (conceptually speaking) a POD-type with the same member data (and hence the same alignment) as T.
You mean like boost::aligned_storage<sizeof(T), boost::alignment_of<T>::value> ?
Pretty much. I think it could do the job. (Although of course it's not THE underlying type in a very strict conceptual sense.)
template<class T> void swap (T& x, T& y) { UNDERLYING_TYPE(T) temp; move_raw (x, temp); move_raw (y, x); move_raw (temp, y); }
This clearly looks like undefined behaviour.
It isn't. :-) The code is guaranteed to swap x and y and leave them in a valid state. temp will be discarded like any POD object, without any chance for unwanted side effects. For clarity, I have already implemented and tested this and everything works as expected.
You cannot use bitwise copy to implement move semantics. That just doesn't work.
It probably depends on what you mean by 'move semantics' and what you mean by 'implement'. What I'm sure of, is that my library can (unintrusively) simulate move constructors, move destructors and the returning of rvalue references from functions. Of course, it doesn't use *only* bitwise copies for that purpose and the type involved needs to be default-constructible. Why do you think it just cannot work? Note that I'm not claiming to deliver a complete library for move semantics -- to the contrary. The underlying type library doesn't predate on Boost.Move; I only think the underlying type library could be useful in the implementation of Boost.Move. For a more thorough discussion please refer to the lecture notes of Alexander Stepanov. He explains these things much better than I could do. :-) -Julian http://www.stepanovpapers.com/notes.pdf