Re: [boost] [config] RFC PR 82

On 12/1/2015 3:16 AM, Domagoj Šarić wrote:

On Thu, 26 Nov 2015 07:43:24 +0530, Agustín K-ballo Bergé wrote:

...

As for the original topic, I am certain that having the proposed macro would be a mistake. Don't try to fool a language/compiler smarter than you, or you will end up getting what you asked for (UB) sooner or later. If you have types whose values are comprised by just a set of bits, and you'd wish to operate on said value representation, then do so by using the tools for operating on the value representation of such trivial types. Type punning via unions is not that tool.

IMNHO that's just generic paranoia and refusing to even look outside the box...we'd still be using C++98 with this kind of thinking (e.g. Boost.Move is 'fooling' the pre-C++11 compiler just like templates weren't originally designed as a tool for TMP or CRTP)... Not to mention that various compilers explicitly prescribe ways to be 'fooled' (union type punning for GCC&compatibles, MSVC does not use the aliasing rules at all - Windows wouldn't boot if it did, etc...)

IMHO this is short-sighted. Boost.Move is a temporary solution until we transition into well-defined semantics, and as such it only has to be supported in those now old compilers that do not support real move semantics. Your code, on the other hand, would have to be verified and supported in every new compiler version that pops up, until the end of time. Now you might think that your code won't be around long enough for it to see compilers improving in this area, given the amount of legacy code around relying on it, but it doesn't have to. Analyzers and sanitizers are growing stronger by the day, and they are designed to catch exactly the kind of bad code that you'd wish to leverage. So even if your code "just works" now (and in the future), it will be a disservice to users when their sanitized runs terminate because of by-design undefined behavior within Boost. The solution is, then, to severe the link to broken dependencies. 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? All these "opinions" are based of course on the abstract notion of a `bitcast` function that intends to exploit undefined behavior to do type-punning via unions. If you'd wish to go forward with it, I'd ask that you present us with a concrete implementation so we can start a technical discussion instead. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com