[petsc-dev] About the future XXXDestroy(&obj) change

[Jed Brown]

On Mon, Apr 11, 2011 at 18:06, Lisandro Dalcin <dalcinl at gmail.com> wrote:

> Hey!... Isn't that the model of DA's in petsc-dev? My current issues
> in petsc4py are more realted to backward compatibility than anything.
> But even if I manage to remove the #define DA DM, petsc4py will still
> use DA for the class name (unless there is some strong arguments from
> any of you).
>

There is no such thing as a DA in petsc-dev. As far as the C type system is
concerned, there is only DM. The dynamic type may be DMDA, but that is not
revealed to the type system. I'm not saying I agree with this choice, but
that's the way it is. This difference in object model is the impedance
mismatch that "typedef DM DA" is covering. Petsc4py does not have GMRES as a
visible subtype of KSP, nor ASM as a subtype of PC, etc.


> > It is not useful to C callers without also having
> > petsc4py/src/include/custom.h.
>
> I you use the new DMDAxxx API' from petsc-dev, you should not need
> petsc4py/src/include/custom.h at all... It is just the #define DA DM,
> and that is required only for the case of using "cimport" in Cython
> code (I mean, SWIG wrappers or hand-written C should not suffer from
> this issue).
>

This means that you have to update your code to the new interface. Matt
seemed to be asserting that petsccompat.h was for backward compatibility (a
way to build your old 3.1 code using petsc-dev/3.2) which is something PETSc
has never supported. I would not immediately object to maintaining one
version of backward compatibility when a macro is activated, but it's a
slippery slope. In any case, include/petsccompat.h does not currently
provide backward compatibility in any meaningful sense.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110411/cb9bbde2/attachment.html>