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

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 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 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@lists.boost.org> 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