From: Peter Sommerlad (peter.sommerlad_at_[hidden])
Date: 2019-06-28 08:12:38
I feel like I am in your boat!
Andrzej Krzemienski via Boost wrote on 28.06.19 10:08:
> Hi Everyone,
> This is not a review of out_ptr, but I wanted to share my thoughts about
> the motivation for this library.
> I do not recall any time from my programming experience where I was in need
> of passing a smart pointer to a T** interface, so maybe this is why I
> cannot appreciate the value of out_ptr.
> On the other hand, if I need to use a library with a C API, or other
> non-C++ API (this happens when someone wants to naively port a Java library
> to C++ and keep the Java interface) the first thing I do is to wrap the API
> functions into a RAII class. It takes some time up front, but then whenever
> it is used, I do not have to deal with the problems of the old API. `T**`
> is only one of the problems.
> The motivation focuses on only easily passing smart pointers to `init(T**)`
> functions, but it does not address the problem of adapting the error
> reporting of `init(T**)`to the error reporting of my program. I would never
> want to only solve the former problem and omit the latter. Also, I would
> never want to represent a handle to a resource with a smart pointer, as I
> do not want to voluntarily inject the null-pointer state that I now have to
> take care of everywhere. Instead I would prefer a dedicated type that is
> not default-constructible, where one really needs to try hard to get the
> special no-resource state (e.g. by moving from and not destroying the
> 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.
> Does anyone else feel the same? Or am I missing something about the problem
> domain? Anyway, I think that this problem should be covered in the
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk