Martin Sandve Alnæs skrev den 20/06-2008 følgende: > 2008/6/20 Garth N. Wells <[EMAIL PROTECTED]>: > > > > > > 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 > [email protected] > http://www.fenics.org/mailman/listinfo/dolfin-dev _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
