Re: [boost] [config] RFC PR 82

Subject: Re: [boost] [config] RFC PR 82
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2015-12-15 19:08:36

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