[Dune-devel] Status of LocalFiniteElement::clone

Carsten Gräser graeser at mi.fu-berlin.de
Wed Oct 25 15:03:07 CEST 2017


Dear Oliver,

Am 25.10.2017 um 10:56 schrieb Oliver Sander:
> Dear Dune,
> 
> I have recently wondered about the status of the 'clone' method that
> is provided by LocalFiniteElementVirtualInterface.  Some implementations
> have it and others don't. LocalFiniteElementVirtualImp has it but does
> not call the corresponding implementation method.  No unit test in
> dune-localfunctions mentions 'clone'.
you will normally not need these in the normal local
finite element (LFE) interface. Because when using a
plain LFE implementation, you have value semantics
and use the copy constructor.

In contrast, if you use the virtual interface, you have
pointer semantics while only knowing the interface type
but not the derived class. Since there are no virtual
copy constructors you introduce the virtual clone()
method that does the trick. Hence any implementation
of the virtual interface has to implement this abstract
virtual method declared in LocalFiniteElementVirtualInterface.
Such that the user call lfe->clone() will do sort of
a dynamic dispatch for the copy constructor.

Since the only implementation of LocalFiniteElementVirtualInterface
is the wrapper class LocalFiniteElementVirtualImp, that's the only
one which needs to implement clone().

From the user perspective, the virtual interface behaves
differently because you have to call clone(). But that's
not a problem because your code will look different
anyway (value vs pointer semantics).

In fact I'd prefer to use type erasure here to get a unified
interface with value-semantics for the user and hide this stuff.

Best,
Carsten




Technical side note:

There's some helper functions used in the constructors
of LocalFiniteElementVirtualImp that seem to generalize
clone(). But this is just a result of my bad SFINAE-fu
when I wrote this. But that's not the only issue in
LocalFiniteElementVirtualImp that could be cleaned up
(e.g. useless double allocation - ouch!).



> 
> Therefore I submitted
> 
>   https://gitlab.dune-project.org/core/dune-localfunctions/merge_requests/66
> 
> which tests every LocalFiniteElement whether it has 'clone'.  Not surprisingly
> this fails badly.  I am unsure how to proceed.  Do I have to implement 'clone'
> for every LocalFiniteElement class?  Or am I testing too much, and those
> few (Lagrange) FEs that actually implement 'clone' do so without reason?
> 
> Advice would be appreciated.
> 
> Best,
> Oliver
> 
> 
> 
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at lists.dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-devel
> 


-- 
Prof. Dr. Carsten Gräser
Freie Universität Berlin
Institut für Mathematik
Arnimallee 6
14195 Berlin, Germany
phone: +49 30 838 72637
fax  : +49 30 838 472637
email: graeser at mi.fu-berlin.de
URL  : http://page.mi.fu-berlin.de/graeser

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20171025/d1b533b0/attachment.sig>


More information about the Dune-devel mailing list