dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Thursday 20 November 2008 23:47:39 Garth N. Wells wrote:
> 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?

I have the latest release 1.3.36 and the bug is still in svn trunk. 

> > 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?

The wrapper code works with boost::share_ptr. I have checked with dolfin by 
temporarily changing all std::tr1::share_ptr to boost::share_ptr.

> >   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? 

We need at least one in FiniteElement.

> This seems to me to be the easiest solution until the swig 
> support for shared_ptr matures.


Johan