On 12/15/2015 8:23 PM, Domagoj Saric wrote:
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).
You make it sound like the committee is unaware of these shiny new C semantics. It isn't. This is deemed a bad idea for C++ along with VLAs, restrict, atomic as a qualifier, you name it...
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)...
You make it sound like Boost.Move invented move semantics. It didn't. Its motivation is to write "portable" C++ code, emulating the "C++0x" move semantics feature in C++03 compilers. I would not oppose to transitionally using the 'union trick' in those implementations where it is known to "just work" until they catch up with `memcpy`, as long as there are technical grounds for it.
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).
These compilers you mention were this is guaranteed also happen to ship `memcpy` as a builtin. Other compilers were this isn't guaranteed also happen to generate "bogus" code (according to your expectations), as stated by members of the community with experience in this particular field. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com