From: Derek G. <fri...@gm...> - 2009-12-01 19:27:09
|
Yes... there are other added benefits as well... like being able to store state information. For instance, you can derive from ExactSolution to implement an exact solution... but make your constructor take information (like coefficients for a polynomial for instance) that are then stored in your class. Then whenever value() (no reason to name it exact_value() by the way) gets called you can use that information. Right now you have to stuff everything into the EquationSystems as parameters and pull them back out... or use global variables. Neither of which is the correct thing to do. Personally though... if you're going to go this far with it... how about fleshing out FunctionBase so that it has gradient() and hessian() functions... and then making ExactSolution inherit from that? We need to find _one_ way to specify "Function" objects in libMesh.... Derek On Dec 1, 2009, at 12:08 PM, Kirk, Benjamin (JSC-EG311) 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. > > 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? > > I'm thinking about this not so much from the perspective of ExactSolution, > but rather from MaufacturedSolution, which I intend to derive from > ExactSolution... > > -Ben > > > ------------------------------------------------------------------------------ > 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 > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |