On Tue, 1 Dec 2009 13:08:17 -0600, "Kirk, Benjamin (JSC-EG311)" <[email protected]> wrote: > there are a number of places where we use function pointers, which seems > like a pretty C-ish way to do a lot of things.
I like C, but a function pointer without a context is crippled. > Take, for example, the ExactSolution class... The user provides a function > pointer which is stored in _exact_value function pointer. > > What if instead we declare a virtual function > ExactSolution::exact_value(...) with the same interface as the function > pointer. The default behavior would the then to just call the function > pointer inside the exact_value() method, but as an alternative the user > could instead override exact_value() in a derived class? This is equivalent to using a function pointer except that the user needs to derive your class to change it's implementation. If that derivation is cheap (i.e. equal effort to writing the function bodies) it's okay except for the messy issue of when a decision needs to be made about which solution is being used (it cannot be deferred until after the ExactSolution object is created). This is a reason not to derive ExactSolution for each physics. What I do (implemented in C, tranlating to C++ language here) is to have an interface (abstract class) for pointwise evaluation of manufactured solutions and corresponding forcing terms. These can be created any time (and changed after a model is running), are normally selected by a command-line option, and offer strong encapsulation (in the sense that you could distribute an implementation as a shared library and it would be first-class after dynamically loading it). > I'm thinking about this not so much from the perspective of ExactSolution, > but rather from MaufacturedSolution, which I intend to derive from > ExactSolution... I would do it the other way around (actually I would keep state out of the interface, but that's an orthogonal issue). The reason is that a manufactured solution is strictly more general than an exact solution. Any code that *uses* a manufactured solution needs to know the distributed forcing term. That won't be present in the interface for an exact solution, so you would need the ugly downcast (ruining all composability). Jed ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
