out_ptr's formal review starts now!

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

out_ptr's formal review starts now!

Boost - Users mailing list
Dear Boost community,

The formal review of JeanHeyd Meneide's out_ptr library starts Sunday, June 16th
and ends on Wednesday, June 26th.

out_ptr is a library for making it easy to interoperate between smart pointers and traditional C-style initialization and allocation interfaces. It also enables doing so in a way that allows library authors to opt into speed optimizations for their smart pointers that give them performance equivalent to typical C pointers (see benchmarks (https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/benchmarks.adoc) and the Standard C++ proposal for more details).

Online docs can be found here:

 https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc

The GitHub repository is available here:

 https://github.com/ThePhD/out_ptr

Also, there is an associated standards proposal:

https://thephd.github.io/vendor/future_cxx/papers/d1132.html

We encourage your participation in this review. At a minimum, please state:

- Whether you believe the library should be accepted into Boost
- Your name
- Your knowledge of the problem domain

You are strongly encouraged to also provide additional information:

- What is your evaluation of the library's:
 * Design
 * Implementation
 * Documentation
 * Tests
 * Usefulness
- Did you attempt to use the library? If so:
 * Which compiler(s)?
 * What was the experience? Any problems?
- How much effort did you put into your evaluation of the review?

All issues discussed during this review will be tracked on the library's
GitHub issue tracker at https://github.com/ThePhD/out_ptr/issues.

Regards,
Zach Laine

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: out_ptr's formal review starts now!

Boost - Users mailing list
On Sun, Jun 16, 2019 at 7:30 AM Zach Laine via Boost-users <[hidden email]> wrote:
>
> Dear Boost community,
>
> The formal review of JeanHeyd Meneide's out_ptr library starts Sunday, June 16th
> and ends on Wednesday, June 26th.

Not yet a review, more like initial thoughts and questions.

I've always used shared_ptr to wrap all kinds of "handles" to objects, including IUnknown and HANDLE on Windows, but even things like OpenGL unsigned int handles. It would be really nice to support such non-pointer handle types, so my initial reaction is that out_ptr doesn't go far enough.

To clarify what I mean by non-pointer handle types, consider that it makes sense to keep an OpenGL shader alive by a shared_ptr<unsigned const>, even though the OpenGL handle itself is an unsigned int, not a pointer. To this end I use the following helper function make_handle, which takes a non-pointer handle and a deleter function, and returns a shared_ptr:

namespace handle_detail
{
  template <class H, class D>
  struct deleter
  {
    deleter( H h, D d ):
      h_(h),
      d_(d)
    {
    }

    void operator()( H * h )
    {
      assert(!h);
      (void) d_(h_);
    }

    H h_;
    D d_;
  };
}

template <class H,class D>
std::shared_ptr<H const> make_handle( H h, D d )
{
  std::shared_ptr<H> p((H *)0,handle_detail::deleter<H,D>(h,d));
  return std::shared_ptr<H const>(
    p,
    &std::get_deleter<handle_detail::deleter<H,D> >(p)->h_ );
}

Then I write a wrapper function for glCreateShader:

std::shared_ptr<unsigned const> CreateShader( unsigned shaderType )
{
  assert(!glGetError());
  if( unsigned s=glCreateShader(shaderType) )
  {
    if( unsigned err=glGetError_() )
      throw ....;
    return make_handle(s,glDeleteShader);
  }
  else
    throw zero_handle_detected();
}

Which in the end is used like this:

std::shared_ptr<unsigned const> sh = CreateShader(GL_VERTEX_SHADER);

As you can see the CreateShader wrapper is verbose and clunky, but easy to use. It would be nice to be able to automate that.

(By the way, it never crossed my mind to pass the shared_ptr, like it is done in out_ptr, instead of returning it. One problem with passing it as an argument is that it makes it impossible to use in a constructor initializer list.)

Which leads to my questions:

- Is it possible for out_ptr to support returning the shared_ptr instead of taking it as an argument?

- Is it possible to support non-pointer handle types as well?

- Can error handling be incorporated? I realize there are different options, but perhaps only two need to be supported: a result<T> of some sort (such types' interfaces are somewhat standard much like smart pointer interfaces are) or throw an exception.

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: out_ptr's formal review starts now!

Boost - Users mailing list
On Mon, Jun 24, 2019 at 5:55 PM Emil Dotchevski via Boost-users <[hidden email]> wrote:
On Sun, Jun 16, 2019 at 7:30 AM Zach Laine via Boost-users <[hidden email]> wrote:
>
> Dear Boost community,
>
> The formal review of JeanHeyd Meneide's out_ptr library starts Sunday, June 16th
> and ends on Wednesday, June 26th.

Not yet a review, more like initial thoughts and questions.

I've always used shared_ptr to wrap all kinds of "handles" to objects, including IUnknown and HANDLE on Windows, but even things like OpenGL unsigned int handles. It would be really nice to support such non-pointer handle types, so my initial reaction is that out_ptr doesn't go far enough.

To clarify what I mean by non-pointer handle types, consider that it makes sense to keep an OpenGL shader alive by a shared_ptr<unsigned const>, even though the OpenGL handle itself is an unsigned int, not a pointer. To this end I use the following helper function make_handle, which takes a non-pointer handle and a deleter function, and returns a shared_ptr:

namespace handle_detail
{
  template <class H, class D>
  struct deleter
  {
    deleter( H h, D d ):
      h_(h),
      d_(d)
    {
    }

    void operator()( H * h )
    {
      assert(!h);
      (void) d_(h_);
    }

    H h_;
    D d_;
  };
}

template <class H,class D>
std::shared_ptr<H const> make_handle( H h, D d )
{
  std::shared_ptr<H> p((H *)0,handle_detail::deleter<H,D>(h,d));
  return std::shared_ptr<H const>(
    p,
    &std::get_deleter<handle_detail::deleter<H,D> >(p)->h_ );
}

Then I write a wrapper function for glCreateShader:

std::shared_ptr<unsigned const> CreateShader( unsigned shaderType )
{
  assert(!glGetError());
  if( unsigned s=glCreateShader(shaderType) )
  {
    if( unsigned err=glGetError_() )
      throw ....;
    return make_handle(s,glDeleteShader);
  }
  else
    throw zero_handle_detected();
}

Which in the end is used like this:

std::shared_ptr<unsigned const> sh = CreateShader(GL_VERTEX_SHADER);

As you can see the CreateShader wrapper is verbose and clunky, but easy to use. It would be nice to be able to automate that.

(By the way, it never crossed my mind to pass the shared_ptr, like it is done in out_ptr, instead of returning it. One problem with passing it as an argument is that it makes it impossible to use in a constructor initializer list.)

Which leads to my questions:

- Is it possible for out_ptr to support returning the shared_ptr instead of taking it as an argument?

- Is it possible to support non-pointer handle types as well?

- Can error handling be incorporated? I realize there are different options, but perhaps only two need to be supported: a result<T> of some sort (such types' interfaces are somewhat standard much like smart pointer interfaces are) or throw an exception.

Sorry for the overquoting; I'm adding JenHeyd (the author), so he can easily share the context here.  He was not subscribed to boost-users previously.

Zach 

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: out_ptr's formal review starts now!

Boost - Users mailing list

On Mon, Jun 24, 2019 at 7:49 PM Zach Laine <[hidden email]> wrote:
Sorry for the overquoting; I'm adding JenHeyd (the author), so he can easily share the context here.  He was not subscribed to boost-users previously.

His name is actually spelled "JeanHeyd".  Sorry for the confusion.  Stupid keybords.

Zach


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: out_ptr's formal review starts now!

Boost - Users mailing list
Dear Emil Dotchevski,

     Thank you for your inquiry. Regarding your questions...

- Is it possible for out_ptr to support returning the shared_ptr instead of taking it as an argument?

     That's not the purpose of this library. This library is to interoperate with pre-existing functions whose interfaces you don't have control of or that can't be brought into the wonderful world of C++: if you had control, you could just -- as you have done with your code -- write a wrapper. The problem is that writing wrappers continually does not scale, and it is very hard to automate that kind of boilerplate until we get the Reflection TS / Static Reflection in C++. This library does not aim to try to write a whole new Boost.Preprocessor based, orfunction-signature-reflection-and-conversion library. That is a massive undertaking, and far beyond the scope of this library.

- Is it possible to support non-pointer handle types as well?

     It already supports non-pointer handle types, because you can specify the pointer type explicitly. We have examples for out_ptr<void*>, but nothing is stopping you from doing out_ptr<int>. I frequently use this in C Style APIs which work with integers. Here is an example of using `int` representing a "file descriptor" with unique_ptr: https://github.com/ThePhD/out_ptr/blob/master/examples/source/std.custom_unique_ptr.cpp#L112

    out_ptr and inout_ptr work out-of-the-box with custom handle types and unique_resource, for example. The following example has a specialization only because it wants to gain the special performance-enhancing properties: but the interface of the handle class in the example is perfectly adequate on its own without the written customization point: https://github.com/ThePhD/out_ptr/blob/master/examples/source/custom.handle.cpp#L82

- Can error handling be incorporated? I realize there are different options, but perhaps only two need to be supported: a result<T> of some sort (such types' interfaces are somewhat standard much like smart pointer interfaces are) or throw an exception.
 
     Since it works with the typical C-style of pointer output parameters, no. If somebody worked on some new, cool library doing some of what I outlined in the answer to your first question: maybe!

Sincerely,
JeanHeyd Meneide

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users