On Saturday 14 February 2009 18:58:42 A Navaei wrote: > 2009/2/14 Johan Hake <[email protected]>: > > [snip] > > > >> >> However, there are problems > >> >> with handling the shared pointer in python. I used this in my swig > >> >> interface file (or in an implicit way you can include dolfin.i > >> >> defining the right flags): > >> >> > >> >> #define SWIG_SHARED_PTR_NAMESPACE std // comment out if it's boost > >> >> #define SWIG_SHARED_PTR_SUBNAMESPACE tr1 // comment out if it's boost > >> >> %include "boost_shared_ptr.i" > >> >> # if defined(SWIG_SHARED_PTR_QNAMESPACE) > >> >> SWIG_SHARED_PTR(Function, dolfin::Function) > >> >> #endif > > > > This has to be done in the dolfin.i file, and not in your interface file > > that %import dolfin.i, otherwise the macros won't kick in for the right > > types. > > > > Not sure what you mean with in an implicit way. > > > > Also, if you %import the development version of dolfin.i you should be > > able to declare your derived class as: > > > > %include <boost_shared_ptr.i> > > SWIG_SHARED_PTR_DERIVED(DolfinImageFunctionImageType,dolfin::Function,itk > >::DolfinImageFunction<ImageType>) > > Why using the derived macro? This is the function of interested for > wrapping: > > class itkImageToDolfinFunctionID2 { > public: > static std::tr1::shared_ptr< dolfin::Function > > Convert(itkImageD2 * imageData); > }; > > (agian, ignore the namings due to template instantiation). So, Convert > returns > > std::tr1::shared_ptr< dolfin::Function > > > type, and _not _ > > std::tr1::shared_ptr< itk::DolfinImageFunction<ImageType> > > > which means we should simply apply the macro to dolfin::Function: > > SWIG_SHARED_PTR(Function, dolfin::Function) > > Is that right? Any, it doesn't wrap!
Ok, I think there some things here. First you cannot use the SWIG_SHARED_PTR(Function, dolfin::Function) in your interface file, as this has to be done in dolfin prior to the class declarations. As already mention shared_ptr in python is _not_ supported in the release version, but is in the development version. If you would have been using the development version you should be able to just return a shared_ptr<dolfin::Function>, without using the SWIG_SHARED_PTR_DERIVED macro, as you point out. If it does not cause any troubles, I would actually run the derived macro in your interface file, just to be sure. I have the general feeling that any things that potentilly can cause type troubles in swig will cause it ;) If you want to try this you have to %import the development version of dolfin.i and just %include boost_shared_ptr.i (this might be superfluous) and then define your derived macro. You can still return the shared_ptr<dolfin::Function> from the Convert function. [snip] > > Yes, shared_ptr in python is not woring properly in the latest release > > version. > > In that case, the problem may not be from my code. Well, that is probably dependent on the eye of the beholder ;) > Does it work in the development version? If so, what could solve > the problem? I would think that just %importing the dolfin.i file would solve it. In the development version we run the SWIG_SHARED_PTR macro for dolfin::Function so any module %importing dolfin.i should also be aware of the type, and swig should correctly create the proxy class. In the meantime you should at least try returning a plain pointer, i.e., *dolfin::Function, and declare it as a %newobject (or do not bother as it will "only" introduce a memory leak). Then you should be able to check if a proxy class is correctly constructed. [snip] > > Again, you do not want to do this as you then won't be able to use your > > overloaded eval function, as the Function will then be treated to be > > discrete, i.e., using the coefficients in _vector together with the basis > > function in the FunctionSpace to interpolate any eval(). > > Yes, that's why I'm working on wrapping shared_ptr. Then you should definetly switch to the development version, or you won't get it to work ;) Johan _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
