Dear all,
I think the set of types with which bitwise move_raw will yield undefined behaviour can be sharply defined: The standard already does. Undefined behavior is a notion of the standard, not of a particular implementation. The standard says that
On 21.08.2011 21:23, Julian Gonggrijp wrote: this technique works only for PODs (trivially copyable types in 0x), nothing else. Of course, for PODs, the compiler-generated special members already do the right thing.
There is no such thing as an underlying type. It's impossible to realise in current C++, but conceptually it exists. To be honest I think a built-in underlying type function (and real type functions in general) would make a very interesting addition to C++.
Conceptually, if you think of classes as "aggregates and then some", there is the underlying aggregate. But you shouldn't think of classes this way. Note that even implementations don't think of classes this way: the Itanium C++ ABI, for example, makes the distinction between "PODs for the purpose of layout" (a superset of PODs as the standard sees them) and other types, and has slight variations in the data layout algorithm for the two categories. So even if you take a class and define an aggregate that matches it member for member, you aren't actually guaranteed that the data layout is the same. This is just another case where it is highly unsafe to use your technique, and I doubt 1 in 100 programmers are aware that such a problem might exist. Sebastian