On Tuesday 09 February 2010 02:28:53 Garth N. Wells wrote: > Anders Logg wrote: > > On Mon, Feb 08, 2010 at 01:43:35PM -0800, Johan Hake wrote: > >> 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. > > > > You could try. I wouldn't mind being able to do A = B + C in C++. > > You can - with MTL4, uBLAS, Armadillo.
and potentially with much better performance. > > But perhaps the complexity of the wrapper clases/interfaces will > > prevent the compiler from finding the suitable optimizations. > > I think that it would get complicated, and it would be hard to ensure > efficiency. Better to leave this to the specialised libraries. Ok, it would only be for convenience. Johan _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
