Re: [boost] [interest] underlying type library

Subject: Re: [boost] [interest] underlying type library
From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2011-08-22 04:32:01

On 21.08.2011 21:23, Julian Gonggrijp wrote:
> 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 
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