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.