[petsc-dev] Why do we use void* instead of PetscObject in PETSc?

Dave May dave.mayhem23 at gmail.com
Sat Mar 2 10:19:35 CST 2019


I think there would be a lot of merit (in the long run) if user contexts,
such as given to KSPSetComputeOperators(), SNESSetJacobian() etc were
changed to be of type PetscObject rather than void*.

Some obvious benefits would be:
[1] Type checking!
[2] User contexts could be readily shared using PetscObjects reference
counter (PetscObjectReferenece()).
[3] User contexts would have a communicator.
[4] User contexts could have textual names associated with them
(PetscObjectSetName()).
[5] Internal to PETSc (e.g. within KSPComputeOperators_SNES) the header of
the context could be checked to ensure the type of the PetscObject is valid
(SNES in this example).

If this change was adopted, the user could readily change their code to use
a PetscContainer. Such a change avoids the user having to recreate their
own object model / class to deal with simple issues associated with sharing
a context, or having to manage communicators within their own contexts.

I see the point that the context is "the users problem". Many PETSc
examples simply use a pointer to typedef'd struct as the context. Users
tend to copy examples, and really, a simple struct with a bunch of
parameters is not a good object model to be followed. Would it be so
horrible to require users to put "their problem" (e.g. context) inside a
PetscObject?

Besides the huge volume of work required to change internal PETSc code and
more over, the code of all users, are there genuinely compelling reasons to
keep using void* everywhere? I cannot think of one, but I would like to
hear others thoughts on this. (Maybe there are concerns with Fortran
compatibility?).


Thanks
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20190302/e157b11e/attachment.html>


More information about the petsc-dev mailing list