[petsc-users] question about the PETSc Vec object and C++ destructors

Mohammad Mirzadeh mirzadeh at gmail.com
Thu Feb 6 00:12:07 CST 2014


There are couple of things you are doing wrong here!

> Shouldn't it be destroying the Vec declared by the very first "thing t",
and hence throwing an error saying that you can't destroy a v that has not
been created?

No. The destructor of an object is called when either 1) manually call
`delete` on an instance allocated via `new` or 2) when the object is
allocated on the stack and goes out of scope. In your case the destructor
for `t` is called when program reaches the end of `main` i.e. when it
terminates.

In your case, you are first creating an empty object using the default ctor
and then assigning it to a temporary object `thing(2)`. Once
the assignment is done, the destructor of the temporary object is called.
Also note that since you have not implemented an assignment operator for
your class, the default is tiled which merely copies `x` which is most
certainly what you want since in PETSc `Vec` is simply an opaque pointer.
This means to properly be able to copy one `thing` to another you need to
implement the assignment operator and most probably also the copy ctor .
See http://stackoverflow.com/questions/4172722/what-is-the-rule-of-threefor
more details on this.

Also If you are going to depend on dtor to destroy pets objects, you need
to implement a class that initializes and finalizes PETSc through ctor and
dtor and call it before calling any other object. Otherwise all other
classes will be calling their dtors after PetscFinalize. Something like
this should serve the purpose

class PetscSession{
public:
PetscSession(int argc, char* argv[]){
PetscInitialize(&argc, &argv, NULL, NULL);
 }
~PetscSession(){
PetscFinalize();
}
};

int main(int argc, char* argv[]){
PetscSession petsc(argc, argv);
// All other classes come after PetscSession has been called
 return 0;
}



On Wed, Feb 5, 2014 at 7:14 PM, Matthew Knepley <knepley at gmail.com> wrote:

> On Wed, Feb 5, 2014 at 8:02 PM, David Liu <daveliu at mit.edu> wrote:
>
>> Hi, this is a question mainly to clear up my understanding of what the
>> Vec object is. Consider the following C++ code:
>>
>> //=========================
>>
>> #include <petsc.h>
>>
>>
>>
>  class thing{
>>
>> public:
>> Vec x;
>>  thing(){};
>> thing(int N){
>> PetscPrintf(PETSC_COMM_WORLD, "x before create = %i\n", x);
>>  VecCreateSeq(PETSC_COMM_SELF, N, &x);
>> PetscPrintf(PETSC_COMM_WORLD, "x after create = %i\n", x);
>>  }
>>  ~thing(){
>> PetscPrintf(PETSC_COMM_WORLD, "x before destroy = %i\n", x);
>>  VecDestroy(&x);
>> PetscPrintf(PETSC_COMM_WORLD, "x after destroy = %i\n", x);
>>  }
>> };
>>
>>
>> int main(int argc, char** argv){
>>
>>  PetscInitialize(&argc, &argv, PETSC_NULL, PETSC_NULL);
>>
>> thing t;
>> PetscPrintf(PETSC_COMM_WORLD, "x before everything = %i\n", t.x);
>>  t = thing(2);
>> PetscPrintf(PETSC_COMM_WORLD, "x after everything = %i\n", t.x);
>>  PetscFinalize();
>> }
>>
>> //=========================
>>
>> The output, when run sequentially, is
>>
>> x before everything = 0
>> x before create = 0
>> x after create = -326926224
>> x before destroy = -326926224
>> x after destroy = 0
>> x after everything = -326926224
>>
>> (among some unimportant error messages). If I try to VecGetSize(t.x, &N),
>> immediately after the line "t = thing(2)", I get an error indicating that
>> t.x has been destroyed.
>>
>> This behavior, as well as the printed output, suggests that the
>> destructor being called during the line "t = thing(2)" is destroying the
>> Vec just created by "thing(2)". Shouldn't it be destroying the Vec declared
>> by the very first "thing t", and hence throwing an error saying that you
>> can't destroy a v that has not been created?
>>
>
> This has nothing to do with Vec, it is about C++ copy semantics. This is
> why I would
> never tell someone to use C++.
>
>     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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20140205/4c402f8b/attachment.html>


More information about the petsc-users mailing list