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: ThePhD (phdofthehouse_at_[hidden])
Date: 2018-07-04 13:29:43

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
>