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