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 ------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140 _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
