On Tue, Jun 10, 2008 at 04:41:25PM +0200, Martin Sandve Alnæs wrote:
> Maybe this design works?
>
> x is coordinates, c is cell info
>
> class Function
> {
> virtual void eval(v, x, c) { eval(v, x); }
> virtual void eval(v, x) { dolfin_error("missing implementation of eval"); }
> };
>
> class A: Function
> {
> void eval(v, x) { do_my_thing; }
> };
>
> class B: Function
> {
> void eval(v, x, c) { do_my_thing; }
> };
>
> The assembler always call eval(v,x,c), the user overloads the one
> he wants. There are already lots of redirecting back and forth in
> the Function hierarchy, so the overhead shouldn't become larger.
> If a user-function that depends on cell info is called in a context
> without cell info, i.e. eval(v,x) is called, this triggers an error.
>
> Inheritance in Python is probably a problem here (SWIG issues).
> Alternatively, name them eval(v,x) and eval_cell(v,x,c) or something
> to solve that problem.Good, but it becomes a bit messy if we also want to include the other hidden arguments (see protected section of Function): /// Access current facet normal (available during assembly for user-defined function) Point normal() const; /// Access current facet (available during assembly for user-defined functions) int facet() const; -- Anders
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
