dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Friday 21 November 2008 09:46:08 Garth N. Wells wrote:
> Johan Hake wrote:
> > On Friday 21 November 2008 00:40:22 Garth N. Wells wrote:
> >> 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?
> >
> > For now yes.
> >
> >> 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.
> >
> > That would come handy. I think we have to figure out the benefits and
> > drawbacks of using shared_ptr in the python interface first.
>
> I suspect that you can avoid having shared_ptr appear in the Python
> interface without significantly impacting functionality.

If we have dual constructors for all classes it won't be an issue. However I 
hoped it would help in the swig memory management, but it doesn't seem to do 
help us much...

> Once you've figured this out, feel free to add a shared_ptr typedef if
> it helps.

Ok.

> > While on the topic, would it be usefull to typdef the, untill now, few
> > base classes that is using shared_ptr? This would make the use of
> > shared_ptr "easier" in user code, e.g.:
> >
> >   #ifdef USE_BOOST_SHARE_PTR
> >   #include <boost/shared_ptr.hpp>
> >   #else
> >   #include <tr1/memory>
> >   #endif
> >
> >   namespace dolfin
> >   {
> >   #ifdef USE_BOOST_SHARE_PTR
> >     typedef boost::shared_ptr shared_ptr;
> >   #else
> >     typedef std::tr1::shared_ptr shared_ptr;
> >   #endif
> >     typedef shared_ptr<Mesh> SharedMesh;
> >     typedef shared_ptr<FunctionSpace> SharedFunctionSpace;
> >     ...
> >   }
>
> Looks a bit complicated to me. Shared pointers won't be visible for the
> majority of applications, so I'm satisfied with how we have it now.

Ok.

Johan