Personally... just force people to inherit from the base class and override
virtuals. It's not _that_ much work....
That's what we do in MOOSE and it's been working well....
Also: Screw backward compatibility. libMesh has been moving away from
function pointer stuff for a while (like Ben's new NonlinearSystem stuff).
Let's move to an all object oriented interface (we can move there slowly
by re-engineering each system separately). The function pointer stuff has
always been an oddity in libMesh for me... it seems so out of place with
all the other object-oriented stuff we have going on...
Derek
On Tue, Jan 31, 2012 at 4:40 PM, Roy Stogner <royst...@ices.utexas.edu>wrote:
>
> I'm tired of having to cook up hard-coded fptr and gptr arguments to
> pass to methods like System::project_vector() and
> ExactSolution::attach_exact_value(); I'd prefer to be able to pass in
> function objects instead.
>
> But I also want to avoid breaking backwards compatibility, so we need
> some species of function object, a WrapperFunction, to be the argument
> to these methods, so that function pointers passed in can be
> implicitly converted to WrapperFunction temporaries.
>
> But I don't want to force everyone to subclass WrapperFunction, so it
> needs to also be constructable from any FunctionBase-derived object.
>
>
> Now here's the dilemma:
>
>
> Strategy A:
> If we have WrapperFunction store a copy of the FunctionBase-derived
> object, then for that copy to be useful we need a
> FunctionBase::clone() method to avoid slicing.
>
> Strategy B:
> If we have WrapperFunction instead store a FunctionBase*, then it
> can't be constructed from a temporary. I.e. users won't be able to
> do:
>
> // case 1
> ExactSolution::attach_exact_value (ZeroFunction()); // grossly contrived
> example
>
> They'll have to do:
>
> // case 2
> ZeroFunction z;
> ExactSolution::attach_exact_value (z);
>
>
> Fortunately we'll be taking a non-const FunctionBase& argument, so
> case 1 will give us a compile-time error rather than a dangling
> pointer, but it's still a tradeoff.
>
>
> I'm leaning towards Strategy B: slightly more annoying syntax for new
> functor users, but no chance of breaking existing code from users who
> have their own classes derived from FunctionBase. Before I finish
> implementing it: anyone else have ideas or preferences?
> ---
> Roy
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Libmesh-devel mailing list
> Libmesh-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
