> On Nov 24, 2015, at 5:59 PM, Derek Gaston <fried...@gmail.com> wrote: > > What is the reasoning behind using UniquePtr for the return type from > MeshBase::sub_point_locator()? > > I actually want to store off multiple sub_point_locators and then dish them > out to other places as needed inside my code... so I really want to use a > std::shared_ptr or at least just a libMesh::AutoPtr. > > 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. > > I was just wondering if there was a particular reason why UniquePtr was > chosen in this instance? In general, I'm still getting my legs under me with > all of the different smart pointers (and typedefs) we are using now... so it > would be good to know if there was a real design decision behind this one. > > Finally, would it be ok to change it to AutoPtr (or a shared_ptr, do we use > those in libMesh yet?).
UniquePtr is AutoPtr if you configure with --disable-unique-ptr. As for why the interface is the way it is, I'm not totally sure, but the typical reason is that Libmesh tries to not hand back any library-allocated pointers which are the user's responsibility to clean up without first wrapping them in memory management containers (see also all the ::build() methods). In your case, releasing them is the way to go, you are just responsible for deleting them yourself. ------------------------------------------------------------------------------ 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
