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
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