2011/8/21 Julian Gonggrijp <j.gonggrijp@gmail.com>
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.
Do you have codes? Something that just works may not be guaranteed to work...
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.
What type needs to be default-constructible? Something like underlying_type_traits<T>::underlying_type or T itself?