On Fri, 11 Mar 2011, Kirk, Benjamin (JSC-EG311) wrote:

> Right now a user can interface with the System class by providing up to five
> function pointers -
>
> (1) initialization
> (2) assembly
> (3) constraints
> (4) QOI
> (5) QOI derivative
>
>
> What do you think about optionally taking pointers to a class derived from
> some pure virtual class(es):
>
>
> class MyAssembly: public libMesh::System::UserAssembly,
>                              public libMesh::System::UserInitialization
> {
>    virtual void initialize();
>    virtual void assemble();
> }

What arguments do we want these to take?  An EquationSystems& and
string as usual?  I'd think a System& would be more elegant, except
that then when someone needed more than a bare-bones System (as
everyone does...) they'd have to downcast it to ImplicitSystem or
some such, whereas at least now we hide the ugly downcasts in
EquationSystems::get_system().

> The user could create a class for each action or put multiple functions in
> once class as shown above.  That seems useful enough to be a reason to avoid
> functors.

These effectively are functors, just with the work done in named
methods rather than operator()().  Being able to handle multiple
inheritance sanely (at least, as sanely as multiple inheritance ever
gets) is a minor point in favor of named methods.

The only point in favor of operator()() is that it's what C++ generic
programming algorithms expect.  And I can't think of any such that
we'd really want to apply to these functions.  They're not
fine-grained enough for TBB, the stuff in <algorithm>, <functional>
and <numeric> doesn't really apply... anyone know of any boost
niftiness we'd be precluding?
---
Roy


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to