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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk