← Back to team overview

dolfin team mailing list archive

Use of share_ptr in PyDOLFIN

 

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.

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

Johan


Follow ups