Re: out_ptr's formal review starts now!

From: Peter Dimov (pdimov_at_[hidden])
Date: 2019-06-27 11:17:59

Gavin Lambert wrote:
> 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.

I agree with this assessment.

In addition, a single macro 
(BOOST_OUT_PTR_CLEVER_UNIQUE_IMPLEMENTATION_FIRST_MEMBER) controls both the 
std::unique_ptr specialization and the boost::movelib::unique_ptr 
specialization, which can't be right.

The implementation should apply the optimization only in the cases where it 
knows with certainty the optimization is safe, and not rely on the user to 
set BOOST_OUT_PTR_CLEVER_UNIQUE_IMPLEMENTATION_FIRST_MEMBER.