Re: [boost] [interest] underlying type library

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

On 08/20/2011 07:33 PM, Julian Gonggrijp wrote:

> Pretty much. I think it could do the job.
> (Although of course it's not THE underlying type in a very strict
> conceptual sense.)

There is no such thing as an underlying type.

>>> template<class T>
>>> void swap (T&   x, T&   y) {
>>>      UNDERLYING_TYPE(T) temp;
>>>      move_raw (x, temp);
>>>      move_raw (y, x);
>>>      move_raw (temp, y);
>>> }
>>
>> This clearly looks like undefined behaviour.
>
> It isn't. :-)

It is. This is not allowed outside of PODs.
Also I assume move_raw here is memcpy. If it isn't, you have strict 
aliasing problems as well.

> What I'm sure of, is that my library can
> (unintrusively) simulate move constructors, move destructors and the
> returning of rvalue references from functions. Of course, it doesn't
> use *only* bitwise copies for that purpose and the type involved needs
> to be default-constructible.
>
> Why do you think it just cannot work?

Well it's pretty obvious that bitwise copy doesn't do the right thing in 
many cases.
User-defined types can pretty much do whatever they want, and changing 
their address may very easy invalidate them.

Some libraries have implemented standard-like containers like that. It 
is a known technique. It's just an utterly broken one.