Re: out_ptr's formal review starts now!

From: Gavin Lambert (boost_at_[hidden])
Date: 2019-06-27 07:27:19

On 27/06/2019 18:11, JeanHeyd Meneide wrote:
> On Thu, Jun 27, 2019 at 12:23 AM Gavin Lambert wrote:
>> And "UB-based optimization" does not inspire confidence.
> 
> There is nothing I can do for standard pointers other than to give up the
> optimization or to use the UB. (This is one of the reasons it was proposed
> to the standard, asides from being an existing practice with wide
> implementation experience.)

Correct me if I'm wrong, but the clever implementation appears to depend 
on several #defines which are entirely undocumented.

Furthermore, one of them selects between whether the private members of 
std::unique_ptr have the pointer as the "first" or "second" member (with 
assumption that the first member is then also pointer-sized), with no 
other options.  This does not seem like the sort of thing that users 
should be required to define or otherwise know at all -- especially in 
code that might be compiled against multiple compilers or multiple 
standard library implementations.  (And while there is a sanity check, 
it is disabled by default, and also merely asserts "oops, I corrupted 
your memory" after the fact.)

And the "clever" version of inout_ptr is enabled by default, with all of 
these undocumented choices.

I sincerely pity the codebase that includes this code.

Avoidance of a few picoseconds copying a raw pointer twice is simply not 
worth this sort of thing.