dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

Johan Hake wrote:
> Hello!
>
> I have worked on getting shared_ptr to work in PyDOLFIN. I have it runnig on 
> my computer but it will require some changes to the code, so I ask the list 
> if anyone have any thought about it.
>
> Using shared_ptr in PyDOLFIN let us converge the interfaces evenmore. E.g. we 
> can instantiate a dolfin::FiniteElement using a 
> shared_ptr<ufc::finite_element>.
>
> I am not sure at this moment if there are any more imediate benefits with it. 
> Some memory issues we have had before is still around, e.g., we need to keep 
> track of some references to not letting them be collected by swig. I would 
> consider this a bug, but I do not know how's it is :)
>
> swig -version >= 1.3.34 supports share_ptr's. It is easy to add an ifdef in 
> the interface file so the wrapper code for the shared_ptr won't be produced 
> for earlier version of swig. 
>
> Even if swig in their documentation claim that one can use 
> std::tr1::shared_ptr, I found a bug which proves different.

I saw a while ago in the swig ChangeLog that shared_ptr fixes were 
incorporated into the swig release following the first release 
supporting shared_ptr. Do these help?

> So I wonder if it is desireable to add shared_ptr for PyDOLFIN, if so we 
> either have to:
>
>   1) change to boost::shared_ptr in the whole code

How does this help?

>   2) patch swig and wait for upstream changes, and still use
>      std::tr1::shared_ptr 
>
> 2 is probably not likely though.
>
> If we do not enable shared_ptr for PyDOLFIN we have to add some constructors 
> taking references in addition to shared_ptr in the code.

I thought that we pretty much had this already. Which classes need extra 
constructors? This seems to me to be the easiest solution until the swig 
support for shared_ptr matures.

Garth

> Johan
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev