dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Saturday 14 February 2009 18:58:42 A Navaei wrote:
> 2009/2/14 Johan Hake <hake@xxxxxxxxx>:
> > [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