On Mon, 20 Oct 2008, John Peterson wrote: > 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.
There's no way around having to do a dynamic cast test in solve(), I don't think. I'd be happy to be proven wrong, though. But anyway, in the long run it's better to have a nice clear interface with the junk like dynamic_cast encapsulated away behind the scenes. >> 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. Yes, but both of them are a MatrixBase. Yes, it is easier to add new classes when someone else has already volunteered to do the work of writing them. ;-) --- Roy ------------------------------------------------------------------------- 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
