dolfin team mailing list archive

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

Johan Hake wrote:
> 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. 

OK.

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

So swig can wrap boost::shared_ptr and not std::tr1::shared_ptr? If we 
need shared_ptr in the Python interface, we could add a typedef/typename 
(whatever it is that you need for a templated class) so we can switch 
easily.

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

You have it now. I just added it.

Garth

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