dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #10772
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