← Back to team overview

dolfin team mailing list archive

  1. dolfin team
  2. Mailing list archive
  3. Message #10779

Re: Use of share_ptr in PyDOLFIN

  Thread Previous • Date Previous • • Thread Next 


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.
Once you've figured this out, feel free to add a shared_ptr typedef if it helps.
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. 

Garth


  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

Follow ups

References

  Thread Previous • Date Previous • • Thread Next