Re: out_ptr review

From: JeanHeyd Meneide (phdofthehouse_at_[hidden])
Date: 2019-06-29 23:01:08

Dear David Sankel,

     I had forgotten to address this other point of the review:

On Thu, Jun 27, 2019 at 10:08 AM David Sankel via Boost <
boost_at_[hidden]> wrote:

> The provided implementation works for smart pointers that follow
> conventions like the standard, but has some additional logic if the types
> happen to be `std::shared_ptr` or `boost::shared_ptr`. This hard coded
> special casing won't work with, say, a company specific shared pointer
> implementation. This relates to my earlier comment that the customization
> point should be simplified.
>

     It would never work with your company's shared pointer, unless your
company happens to employ a shared pointer that contains a `.release()`
method that takes no arguments. I would find it incredibly surprisingly if
someone's shared pointer had a .release() method on it, given the decades
of nomenclature we have had around Boost and Standard smart pointers. And
even then, ensuring that such does not happen requires very little code in
the case that your shared pointer does have a .release() method:

namespace boost { namespace out_ptr {

      template <typename T, typename Pointer, typename... Args>
      class inout_ptr_t<my_company_shared_ptr<T>, Pointer, Args...> {
            static_assert(dependent_type_false<T>::value,
                   "you cannot use inout_ptr_t from a shared pointer "
                  "as there is no way to release and uniquely obtain
ownership "
                  "for the resource from all the shared pointers!");
      };

}} // namespace boost::out_ptr

Sincerely,
JeanHeyd Meneide