[petsc-dev] XXXDestroy() mistaken design in PETSc
Barry Smith
bsmith at mcs.anl.gov
Sat Feb 19 22:35:15 CST 2011
On Feb 19, 2011, at 10:17 PM, Matthew Knepley wrote:
> 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?
Could do that. I think it is equivalent.
>
> 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.
Won't that configure code also have to change all the calls to Destroy() to pass in the &?
My goal was to not change the API (since you feared the universal breakage) hence not add the * to the API. And I hate to have two valid ways of doing the same thing VecFree(Vec*) (for new users) and VecDestroy(Vec) for old users.
Barry
>
> 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
More information about the petsc-dev
mailing list