On 1.12.2015. 15:18, Agustín K-ballo Bergé wrote:
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.
That's all just circular reasoning (silently assuming that some new form of 'bitwise casting', like the 'union trick', already part of the C standard, will never be part of the C++ standard). The "Boost.Move transition into well-defined semantics" at one point had to be started by a typical ugly-hack-workaround probing into not so well defined semantics (i.e. std::auto_ptr)... That compilers like GCC, that otherwise adhere very closely to the C++ language standard in general and aliasing rules in particular, offer explicit, documented, defined ways to work around some difficulties concerning the aliasing rules (e.g. union type punning, may_alias attribute) speaks volumes... For example 'standard' GCC and Clang headers for SIMD intrisics use the may_alias attribute to implement the vector types and pretty much all SIMD extension vendors define intrisics exactly for bitwise casts between vector types. Obviously if they think that memcpy isn't the hammer for every nail there has to be something to it (if nothing else then debug build performance - I really want debug builds of my math code to be at least fast enough so that I can test them in real time). And if compiler vendors have been explicitly offering these 'unholy' tools for years you don't expect them to disappear silently overnight?
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.
Actually yes, since I agreed to move this to Boost.Cast, we can cut this short until then... -- C++ >In The Kernel< Now!