On Mon, Oct 20, 2008 at 8:01 AM, Tim Kroeger <[EMAIL PROTECTED]> wrote: > Dear John, > > One problem would be that this makes it more difficult to differentiate > (e.g. in LinearSolver::solve()) which type of matrix is actually present. > On the other hand, that might easily be solvable using some dynamic_cast > statements (which I am not too familiar with).
Yeah, overload resolution is done at compile time and it may be ambiguous or just choose the first solve() function which works. We'll figure that out when we get there, if worse comes to worst we might have to, as you say, do some dynamic cast tests within the solve function itself, though I hope to avoid that. Another possibility might be to subclass the PetscLinearSolver or create a ShellLinearSolver which implements the desired functionality. There's no reason to completely tie the "shell" concept to the Petsc linear solver, even though that is the only good example we currently have of one. > Also, I would suggest to derive SparseMatrix from ShellMatrix rather than > vice versa. This could actually make SparseShellMatrix unnecessary. This > is of course an advantage of the unification. This one I disagree with. Inheritance should always follow the "is a" organizational semantic, and a SparseMatrix (as we now define it) is most definitely *not* a ShellMatrix. -- John ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
