Inheritance, like PCGAMG to PCMG. One more reason not to use inheritance. On Dec 6, 2012 9:34 AM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:
> > On Dec 6, 2012, at 10:27 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > > > On Wed, Dec 5, 2012 at 6:03 AM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > I think you mean that DMDASNESSetFunctionLocal() sets a function > pointer specific to DMSNES_DA (I don't think you mean to talk about plain > "DM" here (yes I use the wrong object for a fortran function pointer > recently but that was because I was lazy). > > > > Anyways, the cure is that each PetscObject has two fortran pointer > arrays; the current one that handles the methods for the base class of the > PetscObject (for example DMSNESSetFunction()) and the other specific for > the subclass (for example DMDASNESSetFunctionLocal()). When a subclass gets > changed with XXXSetType() the second fortran pointer array is deleted so > you don't get "left over" wrong function pointers. Each subclass manages > its own enums for the subclass so the base class fortran stuff doesn't need > to know about the subclasses. > > > > Does that work? > > > > What about derived classes? Must we have the subtype create set the > number of required Fortran pointers? > > Correct. The subtype manages its own set of pointers (and size) in its > interface functions in the same way as we currently manage them for the > base class. (With enums of course instead of raw numbers). The only thing > that needs to be exposed outside of the fortran interface files is the > freeing of the subclass pointer when the type changes. > > Barry > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121206/633396fd/attachment-0001.html>
