Subject: Re: [boost] [ Interest? ] [ out_ptr ] Tiny C++ Abstraction for C-Style Output Pointers
From: ThePhD (phdofthehouse_at_[hidden])
Date: 2018-07-04 01:48:50
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).
Having to call `.reset()` manually here through `out_ptr` means that if we
want to perform optimizations, we'd likely have to have some way of keeping
track of "already reset" or "already manipulated" (this is why `out_ptr` in
performance tests doesn't meet or exceed the performance of hand-written C
code to manipulate these pointers, and why `inout_ptr` does: see the
performance graphs here -- https://github.com/ThePhD/out_ptr#benchmarks).
There might be room for a type-erased version of `out_ptr` to make
working with smart pointers at an API/ABI boundary simpler, but I think
that goes outside the scope of `out_ptr` and -- indeed -- further outside
the scope of my knowledge...!
On Tue, Jul 3, 2018 at 7:21 PM, Gavin Lambert via Boost <
> On 4/07/2018 01:04, ThePhD wrote:
>> In the proposal linked as part the P.S., that's actually one of the
>> names listed. It was also recommended by another person outside this list,
>> so I will keep that in mind going forward (the pair of names was
>> `c_out_ptr` and `c_inout_ptr`)!
>> This library is not explicitly an annotation, but it also doubles as
>> that by its design: the free function makes it very noticeable that this
>> parameter is an output parameter.
> I guess my question is whether it could be used as a within-C++ annotation
> as well, eg:
> SmartPtr my_smart_ptr;
> auto r = some_function(foo, bar, out_ptr(my_smart_ptr));
> bool some_function(int foo, int bar, out_ptr<SmartPtr> local_smart_ptr)
> local_smart_ptr = x;
> where the out_ptr itself is received by value (cheap to copy or move since
> it just contains a reference to the actual smart pointer), but offers a way
> to alter the value of my_smart_ptr through modification of local_smart_ptr
> -- as close as possible to the behaviour of the argument being type
> SmartPtr&, but requiring the explicit annotation at the call site rather
> than being invisible.
> While serving both roles obviously can't be a requirement (I'm not sure if
> it's even possible), if this can be done then it would truly be deserving
> of a generic name like "out_ptr".
> Unsubscribe & other changes: http://lists.boost.org/mailman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk