Re: [boost] [ Interest? ] [ out_ptr ] Tiny C++ Abstraction for C-Style Output Pointers

Subject: Re: [boost] [ Interest? ] [ out_ptr ] Tiny C++ Abstraction for C-Style Output Pointers
From: JeanHeyd Meneide (phdofthehouse_at_[hidden])
Date: 2018-11-19 01:23:08

Dear Boost Community,

     Just to keep everyone up to date, the discussion has moved over to
Boost.Smartptr as we feel that this would be better made available through
that module: https://github.com/boostorg/smart_ptr/issues/56

     If this does seem acceptable, I will move to also add a friend
declaration to boost::move::unique_ptr, so that individuals using that
library will get the same performance benefits listed in the proposal being
sent for standardization
<https://thephd.github.io/vendor/future_cxx/papers/d1132.html>.

Sincerely,
JeanHeyd Meneide

On Mon, Nov 12, 2018 at 7:05 PM JeanHeyd Meneide <phdofthehouse_at_[hidden]>
wrote:

> Dear Boost Community,
>
>      I wanted to follow-up on this library interest. Because
> interoperation with `boost::move::unique_ptr` would need some coordination,
> it was suggested I put this underneath the boost::move library. I have
> opened an issue to gather the feeling of the maintainer about such a move
> (heh!): https://github.com/boostorg/move/issues/22
>
>      I'll be doing my best to make this available to boost or the open
> source community in some fashion.
>
> Sincerely,
> JeanHeyd Meneide
>
> On Wed, Jul 4, 2018 at 6:29 AM ThePhD <phdofthehouse_at_[hidden]> wrote:
>
>> Dear Gavin,
>>
>>      I think the solution for that is moreso what Jonathan Müller is
>> proposing with his type_safe library. There's a ts::output_parameter type
>> in there that makes your API extremely explicit. Again, this isn't really
>> supposed to affect the callee: only the caller side of things. I don't
>> think `out_ptr` can be shifted over to handle that responsibility without
>> getting very, very far off track.
>>
>>     Maybe `smart_out_ptr` and `smart_inout_ptr`/ (or replace 'smart' with
>> 'fancy') might make the intention more clear, at the cost of being more
>> verbose. 'c_inout_ptr' and 'c_out_ptr` are more cromulent, and generally
>> capture what this API ends up being used for (C and COM-style APIs). My
>> original implementation used `ptrptr` and `in_ptrptr`, as in "pointer to
>> pointer", but I'm not sure anyone liked that name very much except for
>> me...!
>>
>>      Of course, the other authors in the official standards proposal
>> proposed things like `out_ptr` and `inout_ptr`, as well as `c_ptr` and
>> `c_in_ptr`. We went with `out_ptr` and `inout_ptr`.
>>
>> Sincerely,
>> JeanHeyd
>>
>>
>> On Tue, Jul 3, 2018 at 10:17 PM, Gavin Lambert via Boost <
>> boost_at_[hidden]> wrote:
>>
>>> On 4/07/2018 13:48, ThePhD wrote:
>>>
>>>>       I am not sure whether this provides much more benefit than just
>>>> passing the smart pointer itself: the `some_function` already sticks
>>>> `SmartPtr` in its signature (so you might as well just pass the SmartPtr
>>>> itself, since you've already nailed the smart pointer to the signature).
>>>>
>>>
>>> The benefit is, as I said, in making it obvious at the call-site that
>>> the pointer can be modified.  The alternative is:
>>>
>>> Caller:
>>>   SmartPtr my_smart_ptr;
>>>   auto r = some_function(foo, bar, /*out*/ my_smart_ptr);
>>>
>>> Callee:
>>>   bool some_function(int foo, int bar, SmartPtr& local_smart_ptr);
>>>
>>> Where obviously the comment is trying to be an annotation, but as it's
>>> just a comment it has no real effect and is easily forgotten and then there
>>> is no evidence at all (at the call site) that my_smart_ptr can be modified
>>> by the call.
>>>
>>> It's not really a pointer-specific issue, it's just a flaw in C++'s
>>> reference-passing syntax in general.  Some other languages handle this
>>> better by being more explicit about the purpose of a reference parameter.
>>>
>>> So it would be nice if there were a way to have a compiler-enforced
>>> annotation, as long as it doesn't have negative performance impact.
>>>
>>> As I said, this is not really in-scope for what you're trying to do with
>>> your library, but it's a related problem space and it would be nice if one
>>> solution could solve both problems uniformly.
>>>
>>>
>>>
>>> _______________________________________________
>>> Unsubscribe & other changes:
>>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>>
>>
>>