Re: [boost] [interest] underlying type library

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

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?

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

>> In my current implementation move_raw is the compiler_generated POD
>> assignment (the 'overlying type' is reinterpret_cast to the underlying
>> type to enable this).
> 
> Right, this is what I suspected.
> Your code is therefore invalid, and may very well break when you enable optimizations (or not, depending on what the compiler chooses to do).

Code can be fixed.

Thank you for the explanation of the strict aliasing problem.