dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

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.

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

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

Thanks!

Johan