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. > 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. Garth > -- > Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
