Re: out_ptr's formal review starts now!

From: JeanHeyd Meneide (phdofthehouse_at_[hidden])
Date: 2019-06-25 05:27:41

 Dear Emil Dotchevski,

     Thank you for your inquiry. Regarding your questions...

- Is it possible for out_ptr to support returning the shared_ptr instead of
>> taking it as an argument?
>>
>
     That's not the purpose of this library. This library is to
interoperate with pre-existing functions whose interfaces you don't have
control of or that can't be brought into the wonderful world of C++: if you
had control, you could just -- as you have done with your code -- write a
wrapper. The problem is that writing wrappers continually does not scale,
and it is very hard to automate that kind of boilerplate until we get the
Reflection TS / Static Reflection in C++. This library does not aim to try
to write a whole new Boost.Preprocessor based,
orfunction-signature-reflection-and-conversion library. That is a massive
undertaking, and far beyond the scope of this library.

- Is it possible to support non-pointer handle types as well?
>>
>
     It already supports non-pointer handle types, because you can specify
the pointer type explicitly. We have examples for out_ptr<void*>, but
nothing is stopping you from doing out_ptr<int>. I frequently use this in C
Style APIs which work with integers. Here is an example of using `int`
representing a "file descriptor" with unique_ptr:
https://github.com/ThePhD/out_ptr/blob/master/examples/source/std.custom_unique_ptr.cpp#L112

    out_ptr and inout_ptr work out-of-the-box with custom handle types and
unique_resource, for example. The following example has a specialization
only because it wants to gain the special performance-enhancing properties:
but the interface of the handle class in the example is perfectly adequate
on its own without the written customization point:
https://github.com/ThePhD/out_ptr/blob/master/examples/source/custom.handle.cpp#L82

- Can error handling be incorporated? I realize there are different
>> options, but perhaps only two need to be supported: a result<T> of some
>> sort (such types' interfaces are somewhat standard much like smart pointer
>> interfaces are) or throw an exception.
>>
>
     Since it works with the typical C-style of pointer output parameters,
no. If somebody worked on some new, cool library doing some of what I
outlined in the answer to your first question: maybe!

Sincerely,
JeanHeyd Meneide