Dear Gavin, 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...! Sincerely, JeanHeyd On Tue, Jul 3, 2018 at 7:21 PM, Gavin Lambert via Boost < boost@lists.boost.org> wrote:
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:
Caller: SmartPtr my_smart_ptr; auto r = some_function(foo, bar, out_ptr(my_smart_ptr));
Callee: bool some_function(int foo, int bar, out_ptr<SmartPtr> local_smart_ptr) { ... local_smart_ptr.reset(x); and/or 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 /listinfo.cgi/boost