Boost logo

Boost :

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.


Agustín K-ballo Bergé.-

Boost list run by bdawes at, gregod at, cpdaniel at, john at