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: Richard Hodges (hodges.r_at_[hidden])
Date: 2018-07-03 13:53:52

First of all, this library addiion IMHO is a great idea.

On Tue, 3 Jul 2018 at 15:04, ThePhD via Boost <boost_at_[hidden]> wrote:

> Dear Gavin,
>
>      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`)!
>

Which begs the question, couldn't objects be created by fortran, python,
the node v8 engine, c#, java, assembler, etc?

In this regard it seems to me that your existing names are better since
they describe intent rather than implementation.

>
>      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.
>
> Sincerely,
> JeanHeyd
>
> On Tue, Jul 3, 2018 at 12:15 AM, Gavin Lambert via Boost <
> boost_at_[hidden]> wrote:
>
> > On 3/07/2018 14:42, ThePhD wrote:
> >
> >>       This does not have any other use case than C and COM-Style API
> >> interoperability: both `out_ptr` and `inout_ptr` and streamlined
> >> interfaces
> >> purely for this purpose and to make writing against such APIs more
> >> pleasant, more performant, and (most of all) more developer-time
> >> scale-able
> >> than alternative approaches such as wrapping all such
> initialization-style
> >> functions in C++-isms.
> >>
> >
> > Purely for bikeshedding purposes a name like c_out_ptr might be better in
> > that case.
> >
> > When initially seeing "out_ptr" and the syntax in your original email, at
> > first glance it looked like the intent was as a reference wrapper
> > annotation (to make it more obvious at the call site that the pointer
> will
> > be modified on return), rather than the typical "solution" of using an
> > /*out*/ comment or similar non-functional and non-checked annotation.
> >
> > (I suppose you can use std::ref for that purpose, but the intent is less
> > clear.  And perhaps less necessary once compilers and libraries start
> using
> > multiple return values via structured binding.)
> >
> >
> >
> > _______________________________________________
> > Unsubscribe & other changes: http://lists.boost.org/mailman
> > /listinfo.cgi/boost
> >
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>