Re: [boost] [config] RFC PR 82

Subject: Re: [boost] [config] RFC PR 82
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2015-12-01 10:32:36

On 12/1/2015 11:59 AM, Andrey Semashev wrote:
> On 2015-12-01 17:18, Agustín K-ballo Bergé wrote:
>>
>> But what tops it all, what makes this decision a plain and simple
>> mistake, is that this "just works" because implementations map this kind
>> of undefined behavior into specific well-defined behavior. So it's just
>> undefined behavior for the sake of "pretty syntax" (a subjective thing
>> at best). Why then wouldn't you just simply write that well-defined code
>> that these implementations are translating to?
>
> It's not just syntax. If I'm not mistaken, the union-based type punning
> has advantage over memcpy - it allows the code to be constexpr.

No, it doesn't. There's no undefined behavior allowed in a constant 
expression. Furthermore, the rules for `union` member access are 
stronger for constant expressions, there's no common initial sequence 
rule nor anything like it since constant expressions do not work under 
the memory object model. Even compilers with implementation-specific 
behavior would reject it.

> memcpy also has potential to be a function call instead of a few
> instructions (or no instructions at all). I know many compilers are
> aware of memcpy and optimize it, but that's not something one can rely on.

That could merit a technical discussion, please start one so we can get 
some concrete data. After all, it would have to be an implementation 
specific choice, if we don't know whether `memcpy` will be optimized 
then we can't assume that the undefined behavior will do the `memcpy` 
you expect.

Regards,
-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com