[petsc-dev] XXXDestroy() mistaken design in PETSc

[Matthew Knepley]

On Sat, Feb 19, 2011 at 10:08 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>  What about
>
> extern PetscErrorCode  VecDestroy_(Vec);
> #define VecDestroy(a)  (VecDestroy_(a) || (((a) = 0),0))
>
>  Not exactly PETSc style, but allows the switch without changing the API.


Why not let VecDestroy_() take the pointer?

Also, what about having a configure mode that goes back to the old interface
(on by default),
but allow the new one to be configured. Might involve putting in #define
stuff, or changing
files a little, but it seems cleaner.

   Matt


>
>   Barry
>
> On Feb 15, 2011, at 4:47 PM, Barry Smith wrote:
>
> >
> >  In MPI one calls MPI_Comm_free(&comm) to allow the MPI implementation to
> set the pointer explicitly to 0 after the object is destroyed.
> >
> >  In Petsc XXXDestroy() does not pass the pointer (because it seemed too
> unnatural to me in 1994) thus not allowing 0ing the pointer.
> >
> >   Was this a bad design decision? Should it be revisited?
> >
> >   Barry
> >
> >  Two use cases
> >
> > 1) error detection when someone tries to reuse a freed object
> >
> > 2) when removing some objects from a data structure that will be used
> data one currently needs to do
> >
> >  XXXXDestroy(mystruct->something);CHKERRQ(ierr); mystruct->something = 0;
> >
> > instead of the cleaner XXXDestroy(&mystruct->something);CHKERRQ(ierr);
>
>


-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110219/4a1f18d5/attachment.html>