dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #17452
Re: [Branch ~dolfin-core/dolfin/main] Rev 4461: Work on mesh refinement interface.
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.
Garth
This could potentially lead to many changes in DOLFIN where
> we could return by value rather than by reference with the prime
> example being
>
> A = assemble(a);
>
> But does it really handle non-copying of a wrapped PETSc data structure?
>
> --
> Anders
>
>
>>> What if we have
>>>
>>> FooRefinement::refine(old_mesh, new_mesh)
>>>
>>> or similar?
>>>
>>>> ------------------------------------------------------------
>>>> revno: 4461
>>>> committer: Garth N. Wells <gnw20@xxxxxxxxx>
>>>> branch nick: dolfin-nompi
>>>> timestamp: Sun 2010-02-07 21:53:42 +0000
>>>> message:
>>>> Work on mesh refinement interface.
>>>>
>>>> Do not overwrite old mesh inside refinement functions belonging to static classes. Need to keep old mesh to peform update in adapative methods, so previously the mesh had to be copied before calling refine(...).
>>>> modified:
Follow ups
References