Re: [Libmesh-devel] UniquePtr for sub_point_locator?

[Roy S. <roy...@ic...>]

On Wed, 25 Nov 2015, Derek Gaston wrote:

> What is the reasoning behind using UniquePtr for the return type
> from MeshBase::sub_point_locator()?

Self-documentation.

We allocate it, so someone has to free it.  We don't know how long an
app is going to use it, so the library can't free it, so the app has
to free it.  UniquePtr and AutoPtr make that the default behavior, and
so prevent accidental memory leaks.

> For now, I'm going to have to call release() on the UniquePtr and
> then construct a shared_ptr so I can do what I need to here.

Right.

> I was just wondering if there was a particular reason why UniquePtr
> was chosen in this instance?

A combination of "we didn't have any shared pointers yet" and "even if
we did, returning one would make users wonder what was sharing it
internally".

> Finally, would it be ok to change it to AutoPtr

We deprecated AutoPtr; when C++11 is enabled it's a UniquePtr under
the hood now.

This is nice in some ways (you can just toss them in containers if you
know you're using C++11) and debatable in others (you can't hand off
ownership trivially or accidentally).

> (or a shared_ptr, do we use those in libMesh yet?).

We test for them and define LIBMESH_HAVE_CXX11_SHARED_PTR but since
they're not in  C++03 we don't use them in library code.  I love
shared_ptr but I'm too lazy to strip out the Boost version to give us
a fallback.
---
Roy