On Monday 08 February 2010 13:41:29 Anders Logg wrote: > On Mon, Feb 08, 2010 at 01:35:16PM -0800, Johan Hake wrote: > > On Monday 08 February 2010 01:15:12 Anders Logg wrote: > > > On Sun, Feb 07, 2010 at 11:25:28PM +0000, Garth N. Wells wrote: > > > > Anders Logg wrote: > > > > > On Sun, Feb 07, 2010 at 10:58:44PM +0000, Garth N. Wells wrote: > > > > >> Anders Logg wrote: > > > > >>> This looks a like a non-optimal solution. Are you returning the > > > > >>> mesh by value? That will lead to creation of a temporary and > > > > >>> copying of the entire refined mesh. > > > > >> > > > > >> So they used say ;). Apparently modern compilers are all clever > > > > >> enough not to. > > > > >> > > > > >> Garth > > > > > > > > > > Is that really so? Do you have any good references that explain > > > > > this in detail? > > > > > > > > http://en.wikipedia.org/wiki/Return_value_optimization > > > > > > > > and from 'man gcc' > > > > > > > > -fno-elide-constructors > > > > The C++ standard allows an implementation to omit creating a > > > > temporary which is only used to initialize another object of the same > > > > type. Specifying this option disables that optimization, and forces > > > > G++ to call the copy constructor in all cases. > > > > > > ok, seems correct. I tried the following piece of code with some > > > debugging added to the copy constructor and assignment operator in > > > class Mesh: > > > > > > Mesh refined_mesh_1 = UniformMeshRefinement::refine(mesh); > > > > > > Mesh refined_mesh_2; > > > refined_mesh_2 = UniformMeshRefinement::refine(mesh); > > > > > > The first refinement does not lead to any call to either of the copy > > > constructor or assignment operator. > > > > > > The second call leads to one call to the assignment operator. > > > > > > This is expected but means we need to be careful with how the > > > refinement is called (on the same line as initialization). > > > > > > Should we have a look and see if there are other places where we could > > > return by value? > > > > The operator* and operator+ were explicitly not included because they > > needed to be implemented as a return by value method. Now they can be > > added in the same way as the Python equivalents I think. > > You mean in the linear algebra interface?
Yes. Johan _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
