dolfin team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/6/20 Garth N. Wells <gnw20@xxxxxxxxx>:
>
>
> Martin Sandve Alnæs wrote:
>>
>> 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?)
>>
>
> In many cases, this isn't needed. Pointers have been used for privare arrays
> which are (re)sized at runtime and aren't passed around, e.g.
>
>  uint* connections
>
> in MeshConnectivity.
>
>> 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.
>>
>
> Smart pointers could be useful in some cases. Boost also provides some
> elaborate smart pointers.
>
> Garth

std::tr1::shared_ptr is the standardized boost::shared_ptr.
Boost also has some other variants, I guess it's not a problem
to use them since we already depend on boost, but
std::tr1::shared_ptr is more standard and may be enough anyway.

--
Martin