[petsc-dev] Counting Fortran function pointers

[Jed Brown]

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.html>