[Dune] [#564] Use dynamic polymorphism

[Dune]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#564 - Use dynamic polymorphism
User who did this - Jö Fahlke (joe)

----------
I'm not sure, whether everyone understands each others proposals correctly (I
certainly don't).  In the following I'm summarizing what *I* undestand.
Please edit this comment if I misrepresent your proposal so everyone knows
what we're talking about.

Static-implementation proposal
==============================

First there is the proposal from Peter (a.k.a. "1)") which I understand as
follows:

 0. Have a set of static base classes (StaticLocalFiniteElementInterface,
    StaticLocalBasisInterface, StaticLocalCoefficientsInterface, and
    StaticLocalInterpolationInterface).  These base classes get the following
    template parameters, as apropriate:

    - The C0LocalBasisTraits, C1LocalBasisTraits or CkLocalBasisTraits as
      apropriate.

    The interpolate() method (and the methods for my experimental global
    interface) are template methods.

 1. Have a library of static local finite elements derived from that (as it is
    now), for the people who would like the static version.

 2. Have a set of virtual base classes (VirtualLocalFiniteElementInterface,
    VirtualLocalBasisInterface, VirtualLocalCoefficientsInterface, and
    VirtualLocalInterpolationInterface).  These base classes must have the
    following template parameters, as apropriate:
    
    - The C0LocalBasisTraits, C1LocalBasisTraits or CkLocalBasisTraits as
      apropriate,

    - The function type F which may be interpolated, and

    - The type C used for the coefficients.

    - (In addition, for the global interface I'm currently experimenting with,
      the type of the geometry would also be required)

    This means the the template methods which are currently in place would
    move their template parameters to the class in the virtual interface.
    Thus you need to specify the kind of function and the coefficient type
    earlier, but that is just the price you have to pay with virtual
    inheritance anyway.  (Of course you can use virtual base classes for the
    template parameters, so that is not really an issue).

 3. Have a set of derived wrapper templates
    VirtualLocalFiniteElement<StaticLocalFiniteElement>,
    VirtualLocalBase<StaticLocalBase>,
    VirtualLocalCoefficients<StaticLocalCoefficients>, and
    VirtualLocalInterpolation<StaticLocalInterpolation>.  Each of those
    classes can be constructed with an instance of the underlying class.

That makes a total of 8 template classes you have to write so poeple can use
the virtual interface on top of the static interface.

Virtual-implementation proposal
===============================

Next we have Carstens proposal which I understand as follows:

 0. A set of virtual base class templates VirtualLocalFiniteElementInterface,
    VirtualLocalBasisInterface, VirtualLocalCoefficientsInterface, and
    VirtualLocalInterpoaltionInterface.  These base class must have the
    following template parameters, as apropriate (same as the template
    parameters from Peters proposal above):

    - The C0LocalBasisTraits, C1LocalBasisTraits or CkLocalBasisTraits as
      apropriate,

    - The function type F which may be interpolated, and

    - The type C used for the coefficients.

    - (In addition, for the global interface I'm currently experimenting with,
      the type of the geometry would also be required)

 1. Every implementation of the local finite elements provides a set of
    classes derived from those classes (VirtualLocalFiniteElement,
    VirtualLocalBasis, VirtualLocalCoefficients, and
    VirtualLocalInterpoaltion).

 2. Have a set of static base classes (StaticLocalFiniteElementInterface,
    StaticLocalBasisInterface, StaticLocalCoefficientsInterface, and
    StaticLocalInterpolationInterface).  These base classes get the following
    template parameters, as apropriate:

    - The C0LocalBasisTraits, C1LocalBasisTraits or CkLocalBasisTraits as
      apropriate,

    - The function type F which may be interpolated, and

    - The type C used for the coefficients.

    - (In addition, for the global interface I'm currently experimenting with,
      the type of the geometry would also be required)

    The interpolate() method (and the methods for my experimental global
    interface) are non-template methods, since they cannot be template methods
    in the underlying virtual classes anyway.

 3. A set of static wrapper classes
    (StaticLocalFiniteElement<VirtualLocalFiniteElement>,
    StaticLocalBasis<VirtualLocalBasis>,
    StaticLocalCoefficients<VirtualLocalCoefficients>, and
    StaticLocalInterpolation<VirtualLocalInterpolation>) which are derived
    from the static interface classes above.  Each wrapper class gets an
    instance of its virtual pendant on construction.

That makes a total of 8 template classes you have to write so poeple can use
the static interface on top of the virtual interface.

Select-at-configure-time proposal
=================================

There also seems to be the possibility to switch between virtual and static
inheritance at compile time (like Oliver implemented it) but that was just for
perfornance testing and nobody seriously thinks about that.

----------

More information can be found at the following URL:
http://www.dune-project.org/flyspray/index.php?do=details&task_id=564#comment970

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.