out_ptr review

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2019-06-29 15:27:17

Dear All,

This is not much of a review but I'm going to post it anyway...

I'm not convinced that std:: or boost:: is the right place for 
something whose purpose is to provide compatibility with C APIs.  
That's not to say that the functionality is not valuable to some, 
just that Boost and especially std:: are huge and would, IMHO, 
benefit from focusing on their limited resources on core C++ things. 
There is nothing wrong, nothing "second-class", about releasing 
code to the world yourself without it being in std:: or boost::.

I have had a look at some of the places where I have C++ wrappers 
around C APIs.  In most cases there is some subtlety which makes 
out_ptr not applicable.  For example, the OpenGL APIs often have 
out-parameters, but they are integer handles, not pointers. 
Example:

class Framebuffer: boost::noncopyable
{
  GLuint handle;
public:
  Framebuffer() { glGenFramebuffers(1, &handle); }
  ~Framebuffer() { glDeleteFramebuffers(1, &handle); }
};

Another interesting example is libpng, where my PNG reading code 
makes two create calls, each returning a pointer, but a single 
destroy call that destroys both (much simplified):

class ReadPngFile: boost::noncopyable
{
  png_structp png_p;
  png_infop info_p;
public:
  ReadPngFile():
    png_p( png_create_read_struct(); ),
    info_p ( png_create_info_struct(); )
  {}
  ~ReadPngFile() {
    png_destroy_read_struct(&png_p,&info_p);  // destroys both.
  }
};

I always try to encapsulate these things in small wrapper classes, 
as above, so that the C create and destroy calls are always within 
a few lines of each other and are "obviously" correctly paired.  
I don't think out_ptr would add any safety in these cases - in fact, 
it's one additional layer of complexity to get wrong.  Having read 
the "caveats" section in the documentation, I fear there are really 
too many ways in which a user could be tricked into thinking that 
out_ptr is making their code safer when in fact it is not.  For 
example I would definitely not assume that a C API will set an 
out-parameter to null on error without carefully reviewing its 
documentation!

I would be interested to know which specific C APIs the author or 
others have used with out_ptr.

Regards, Phil.