Re: [petsc-dev] XXXDestroy() mistaken design in PETSc
On Tue, Feb 15, 2011 at 7:58 PM, Barry Smith <[email protected]> wrote:
On Feb 15, 2011, at 5:26 PM, Matthew Knepley wrote:
On Tue, Feb 15, 2011 at 4:47 PM, Barry Smith <[email protected]> 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
We catch this with other error detection. I do not think we would gain much here.
No really. If I do MatDestroy(mat); MatMult(mat,x,y); then it is possible that MatMutl() will crash while looking around inside where mat points. If MatDestroy(&mat); zeroed mat then MatMult(mat,x,y) could do the safe test of if (!mat) nice error message.
I agree, but the immediate type test at the start of MatMult() has caught most things for me. I do not consider double-free a recoverable error, so a SEGV is alright here as well. Matt
Barry
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);
True, but again I do not think the win is large.
Matt
-- 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
-- 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
participants (1)
-
Matthew Knepley