dolfin team mailing list archive

[Ola Skavhaug <skavhaug@xxxxxxxxx>]

Martin Sandve Alnæs skrev den 20/06-2008 følgende:
> 2008/6/20 Garth N. Wells <gnw20@xxxxxxxxx>:
> >
> >
> > Dag Lindbo wrote:
> >> Hello!
> >>
> >> I attach a script that runs Valgrind (memcheck) on all C++ demos (based
> >> on the one that just runs all demos). My suggestion is that this be
> >> included in the testing procedure.
> >>
> >> At present (on my machine) 17 of 31 demos result in a memory leak (!)
> >> None of the demos produce a memory error.
> >>
> >> Note that most, but not all, leaks are due to XML parsing. Are these
> >> really leaks? It is impossible for vg to understand memory pools and
> >> other exotic memory management that are not explicitly freed. Glib does
> >> this in the GTS interface. Maybe libxml2 does something similar. In that
> >> case, I can easily provide a suppression for xml2.
> >>
> >
> > I took a look and fixed at least one leak, but a few others don't look
> > like leaks to me. Part of the problem is that I think we're using
> > pointers is some classes where std::vector would be more appropriate,
> > particularly in the mesh and dof map classes, which is a source of
> > potential leaks and makes ownership unclear.
> >
> > Is there a reason that we use pointers for various arrays in the mesh
> > classes rather than std::vector?
> 
> I believe you cannot get the pointer to std::vector content?
> (At least not safely and portable?)

No, but I have heard that it is very common to do it anyway. You simply 
set a pointer to the first entry in the vector...

Ola
 
> An alternative may be to use shared_ptr<real>,
> if several classes are to use the same memory.
> 
> The main backsides are more template syntax
> and no python support. The latest swig is supposed
> to have support for using shared_ptr with python.
> 
> If you want to try shared_ptr for arrays, you need to
> define an array deleter, I can dig up the code
> if anyone's interested.
> 
> -- 
> Martin
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev