New issue 58 by Princess...@gmail.com: Switch model copying paradigm
http://code.google.com/p/cyclus/issues/detail?id=58
Change from this:
...
old_model...
...
Model* new_model = model_creator();
new_model->copyFresh(old_model);
To this:
...
old_model...
...
Model* new_model = old_model.clone();
This eliminates the need for a separate copyFreshModel method and makes the
code more intuitive to me.
-- -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: http://bit.ly/pphw-cal Associate Professor, Engineering Physics. ~ http://cnerg.engr.wisc.edu Chair, Energy Analysis & Policy Program ~ http://nelson.wisc.edu/eap
option 1:Only the Model base class will actually allocate memory for a new model using the 'new' statement. The copy methods of Model sub (and sub-sub) classes will invoke the copy method of their parents (in order to 'inherit' for free the contents of that copy method). Each copy method must dynamic cast the return value of its parent's copy method into its own type (and return it).
option 2:The initially called sub (or subsub) copy method will allocate memory (using the 'new SubSubModel' statement). This copy method must complete the entire copy operation (including for member variables of parent classes).
This is the correct way to do it. But subclasses don't need to (and shouldn't) copy the member variables of their parent classes. Each class should do copying of its own members only. The correct way to implement my above example is to use copy constructors:A* A::clone(){return new A(*this);}B* B::clone(){return new B(*this);}The key to making this work will be in the copy constructor of B, which begins by calling the copy constructor of A:B::B( const B& copyfrom ): A( copyfrom ){// copy B's member variables}
- accidentally copying over IDs, handles
- invalid use of templates (the first model of a certain implementation to be loaded) rather than their clones within the simulation (ask matt or paul about this. my written explanation will not be clear.
- it is necessary that we copy an object as deeply as possible, never accidentally failing to populate its implementation level (RecipeReactor) member data.
It is clear enough. We want a model initialized to the default state (as defined by xml) - not to the morphed state that exists in the simulation at the time of the copy.