Re: [boost] [interest] underlying type library

Subject: Re: [boost] [interest] underlying type library
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-08-21 19:03:24

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.