Re: out_ptr -- alternatives

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-06-28 11:00:05

pt., 28 cze 2019 o 12:09 Rainer Deyke via Boost <boost_at_[hidden]>
napisał(a):

> On 28.06.19 10:08, Andrzej Krzemienski via Boost wrote:
> > What I am missing from the motivation of out_ptr is the comparison with a
> > full RAII wrapper solution. You can argue that the scope of out_ptr is
> just
> > different: provide interpoperation between `init(T**)`functions and smart
> > pointers. But I would argue that this latter goal is wrong. In fact, I am
> > concerned that we might be encouraging a bad programming style: "need to
> > work with init(T**) APIs? use shared_ptr." instead of promoting RAII
> > wrappers that directly wrap the resource.
>
> It seems to me that out_ptr is a useful tool for writing such wrapper.
>
> class my_wrapper {
> public:
>    my_wrapper() {
>      if (acquire_my_c_resource(out_ptr(this->p))) {
>        handle_error();
>      }
>    }
>    // No need to muck about with destructor or copy/move constructors
> private:
>    std::unique_ptr<my_c_resource, void (*)(my_c_resource *)>
>        p{nullptr, release_my_c_resource};
> }
>

Technically true, but now the advantage of out_ptr seems so minimal that
the costs of including it or reading the documentaiton outweigh the
benefits.

Regards,
&rzej;

>
> --
> Rainer Deyke (rainerd_at_[hidden])
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>