While pondering the FEMContext stuff, I noticed a few problems with our other uses of dynamic_cast:
We used it a lot for downcasting where we know the result of a static_cast should always succeed in correct code, and where outside of debug mode we didn't even bother checking the result. Nothing in inner loops, but unnecessary RTTI is still unnecessary. We sometimes didn't check the result even in debug mode; if such a downcast failed then instead of a nice assertion failure and backtrace we'd just get a segfault. Even when we did properly check the result, that's the same pattern of a couple lines of code over and over again, screaming to be refactored. So it's refactored. libmesh_assert_cast<> should assert a valid dynamic_cast<> in debug/devel modes, or should do a static_cast<> in opt mode. And I'm probably going to end up using this for the Diff/ FEM/ WhateverContext arguments, too - it looks a little uglier than John's idea, but it's a little more intuitive, requires a little less work to create new Context classes, and might be easier for a compiler to optimize away. As a side note, this doesn't *completely* eliminate the raw use of dynamic_cast in libMesh. There turned out to be 4 instances from Ben and one from me of actually using dynamic_cast to switch between different non-error code paths depending on type information. Fancy. Also, Derek's got a dynamic_cast or two operating on a virtual base class, which I didn't replace, because static_cast shouldn't work on virtual base classes and because inbred inheritance trees scare me. --- Roy ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
