On Thu, 13 Sep 2012, Paul T. Bauman wrote: > So how would you like the attachment of an external > DifferentiableQoI to work? I already learned the hard way that > having an AutoPtr stashed that is initialized with a this pointer is > a bad idea (it's amazing how quickly it ate up 12GB of RAM).
Hah! Yeah, the DiffSystem destructor would call the AutoPtr destructor, which would call the DiffSystem destructor, which would call the AutoPtr destructor... I'm surprised you didn't just die when it ran out of stack space, though; there shouldn't have been any heap allocation involved there and I didn't *think* the stack was allowed to grow to 12GB by default. > But, I really like the paradigm that's used in FunctionBase (among > others), namely creating a new copy so the user doesn't have to > worry about the management of the cloned guy or worry about his > version getting destroyed and effecting the pointer that was passed > in. Me too. I don't see how we can pull that off here, though. > So should the clone create a new guy Definitely not in the most general case. The whole point of separating out Physics etc. into separate objects is that it's too heavyweight and error-prone to do things like cloning a System. > Or just the user pass in a pointer and they're responsible for > maintaining the memory through the calculation? (I really don't like > this because it'll really muck up things like a QoIFactory or > something.) This is what I'd been planning on doing, in the back of my mind. I like to think that by the time I'd thought about it as long as you have now, I'd have also reached the conclusion that it was a dumb idea. > Something else? Basically, it seems to boil down to how to handle > the fact that the default diff_qoi is a this pointer. Are you > requiring C++11 compilers yet so we could use a shared_ptr? No, we're trying to stay C++03 compatible and we haven't even made boost a requirement yet. Plus, shared_ptr just does dumb reference counting; give reference-counting a pointer graph with any loops and you get a memory leak (and in C++ a RAII failure). So here's my idea... it's ugly from the library perspective but it'll work well from the users' point of view: We add clone() methods for the Physics etc. classes. In the base classes, they're pure virtual. In the DiffSystem class, they're overridden by a libmesh_error(). In user classes, they'll be overridden by "return a pointer to a new copy of this". The DiffSystem::attach_* methods then use clone() under the hood. This means you can't attach a System to another System, but since that would be a horrible idea and the only reason we're even allowing a System to be a Physics in the first place is backwards compatibility, that's okay. The underlying pointer storage uses a raw pointer. In the DiffSystem destructor, if the raw pointer == this then we do nothing, otherwise we delete it. (note that this means wrapping the raw pointer in a const-only accessor is critical). Copying this to libmesh-devel in case anyone else has ideas/suggestions. --- Roy ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
