Re: [boost] [interest] underlying type library

Subject: Re: [boost] [interest] underlying type library
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2011-08-21 19:53:09

Mathias Gaunard wrote:

> 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.

... which differs from move_raw only in the sense that move assignment 
guarantees that the source is left in a valid state while move_raw 
does not. The latter has an obvious potential for being more 
efficient.

Note that move_raw is not inherently required to operate in a bitwise 
fashion; the bitwise approach is only a default solution to make raw 
moves available to types which don't define their own raw move.

>>> 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.

The underlying type is the solution to the fact that move_raw does not 
guarantee the source to be left in a valid state. Because of that it 
is defined to be a POD type which can store the state of its overlying 
type. As such, it is not "just data"; it has a very clear, semantic 
relation with its overlying type. Again, my proposal is just a default 
solution to fill in for types which don't specify their own underlying 
type.

Perhaps some formal language can illustrate the semantics of move_raw 
and the underlying type:

(semantics of copy assignment, quoted from Alexander Stepanov)
assert(b == c); a = b; assert(a == b && b == c)

(weaker semantics of move assignment, adapted from Alexander Stepanov)
assert(b == c && &b != &c); move(b, a); assert(a == c); assert(valid(b));

(still weaker semantics of move_raw, adapted from Alexander Stepanov)
assert(b == c && &b != &c); move(b, a); assert(a == c);

UNDERLYING_TYPE(T) is a POD type such that the following code is 
valid:
move_raw(a, u); move_raw(u, a);

(where a, b, c are instances of some copyable or moveable type and u 
is an instance of the underlying type of a.)