On 08/22/2011 12:53 AM, Julian Gonggrijp wrote:
Mathias Gaunard wrote:
On 08/21/2011 09:23 PM, Julian Gonggrijp wrote:
However, as Vicente Botet (and Alexander Stepanov) pointed out, there are still valid use cases for the bitwise move_raw mechanism.
Care to point out one that wouldn't be better handled by move constructors?
Any case where the object to move a value into has already been constructed?
Well, there is also move assignment.
The layout of non-PODs is completely implementation-defined. Therefore there couldn't be anything meaningful for "underlying type". All it could be is a sequence of bytes of a certain size with a certain alignment.
The layout may be implementation-dependent but the semantics is not. Since underlying types are defined by their semantics and not by their implementation, I don't see how any implementation issue could affect their existential status.
Data has layout, code has semantics. What you call the "underlying type" is just data, so I don't see how it could have any semantics. Maybe you mean a POD type that's allowed to alias the original type? The closest thing to this is a union that contains both the POD and the original type, which is possible in C++0x.