I gotcha - that makes sense. Thanks for being patient and explaining it to me.
For some reason the one-level of indirection between AutoPtr, UniquePtr and std::shared_ptr, std::unique_ptr and "auto_ptr" has always given me trouble ;-) I'm working on it... Derek On Mon, Mar 21, 2016 at 10:18 PM John Peterson <[email protected]> wrote: > > > On Mar 21, 2016, at 9:04 PM, Derek Gaston <[email protected]> wrote: > > On Mon, Mar 21, 2016 at 9:48 PM John Peterson <[email protected]> > wrote: > >> This mistake should only even be possible if your UniquePtr is still a >> std::auto_ptr. Are you configured with --enable-unique-ptr? I don't think >> it's an issue with the libmesh interface, it's a well-known issue with >> std::auto_ptr that was masked by your use of "auto". >> > > If this is true (that a UniquePtr has different behavior if you use > --enable-unique-ptr) then it DEFINITELY has nothing to do with my use of > "auto". > > Look: if I hadn't used "auto" I would have written this line like so: > > UniquePtr< NumericVector< Number > > solution_vector = > output_system.solution; > > > Yeah, I think the issue here is that --enable-unique-ptr should be the > default (not sure why I never updated the default once we had gotten it > working) and then this would have been a compile error as intended... that > was why I added the UniquePtr stuff in the first place. > > I agree that the interface is dangerous, but it's old... and it's kind of > hard to deprecate because it's a public member. > > > > ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
