On Oct 18, 2010, at 6:26 AM, Jed Brown wrote: > On Mon, Oct 18, 2010 at 03:25, Barry Smith <bsmith at mcs.anl.gov> wrote: > DAXXX() routines are now either DMXXX() or DMDAXXX() see petscdm.h for details > > I'm a little concerned about this because all of these have implicit > downcasting with no RTTI, so they are all totally unsafe. When DA was a > distinct type, you couldn't call DAGetCorners with a DM that was not also a > DA. Now the user has a generic DM, but almost every call they will make is a > memory error if their DM is not DMDA. It could be made runtime-safe by > putting RTTI guards at the top of every public DMDA* function, but runtime > type checking is not as good as compile-time if the latter is reasonably > achievable.
The lack of the runtime "checking" (actually using the Queryfunction business like KSPGMRESSetRestart()) is only due to lazyness on my part, not design. Eventually all the DMDAXXX() will use the query and thus have the runtime checking. As with KSPGMRESSetRestart() there is no compile time checking. Barry > > Note that PETSc itself (for multigrid, DD, etc) works almost exclusively with > the DM API and should not need to call the DMDA API directly (specialization > is via DMOps). In contrast, user code is specialized to a particular > implementation of DM, and pretty much always uses the specialized API. The > old API was safer because the API that the user called was explicitly > specialized, rather than implicitly downcasted from DM. > > Of course I agree that DM organization was messy, but I'm not convinced that > this change is an improvement for the user since it gives up a lot of safety > and offers little in return. > > Jed
