It seems you can do that by using
%apply SWIGTYPE *DISOWN {Bar* hello};
Foo::addBar (Hi *hi, Bar* hello);
it works in python and tcl. You can look in the python
library, look for 'DISOWN'. This is just a modified
'in' typemap:
%typemap(in) SWIGTYPE *, SWIGTYPE []
"if ((SWIG_ConvertPtr($input,(void **)(&$1),$1_descriptor,
SWIG_POINTER_EXCEPTION | $disown)) == -1) SWIG_fail;";
%typemap(in) SWIGTYPE *DISOWN
"if ((SWIG_ConvertPtr($input,(void **)(&$1),$1_descriptor,
SWIG_POINTER_EXCEPTION | SWIG_POINTER_DISOWN)) == -1) SWIG_fail;";
Marcelo
Ben Bornstein wrote:
On May 24, 2004 18:24, Luigi Ballabio wrote:
> I think the real question is: how can you prevent Ruby and C++ from
thinking
> they both own the object.
Hi Meinrad, Henri, Luigi, All,
By its very nature this problem isn't specific to a particular
language binding. We've run into the same issue with our Java and
Python SWIG-generated APIs. It would be great if SWIG had something
akin to %newobject, so that you could tag a particular function or
method as taking over ownership of an object. Perhaps:
%releaseobject Foo::addBar (Bar* b)
If addBar() were to take multiple object arguments, I'm not sure the
best way to indicate which object is to be released by SWIG (by "best"
I mean in a manner most consistent with SWIG syntax). I bet the
one-object addXXX() case would be sufficient in most cases.
Let me tell you how we solved this problem in Python and Java.
Hopefully this will give you some ideas for Ruby. My co-worker and I
are still SWIG newbies, so if anyone has a better way to do this, we'd
be excited to learn.
The basic idea is rewrite each shadow/proxy class method that takes
ownership of an object. Inside the method we set the object's
ownership flag to false:
For Python, we used the SWIG shadow feature:
%feature("shadow") ListOf::append(SBase*) %{
def append(*args):
if args[1]: args[1].thisown = 0
return _libsbml.ListOf_append(*args)
%}
In Java we could not find the shadow feature or it's analog (SWIG
1.3.21), so our solution was a bit more laborious:
%javamethodmodifiers ListOf::append "private";
%rename(appendInternal) ListOf::append;
%typemap("javacode") ListOf
%{
public void append (SBase item)
{
libsbmlJNI.ListOf_appendInternal(swigCPtr, SBase.getCPtr(item));
if (item != null) item.swigCMemOwn = false;
}
%}
We rename the original append() method to appendInternal() and make it
private so no one outside the class can call it. We then insert our
own definition for append() that delegates to the real append() (now
appendInternal()). At first we thought %ignore might work to turn-off
automatic generation of the shadow class method, but it also turns off
the lower-level static JNI function as well (obvious in retrospect).
As you can see, this can get a bit tedious, which is why we would like
to have something like %releaseobject, mentioned above.
I hope this helps.
Thanks.
Ben
_______________________________________________
Swig maillist - Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig
_______________________________________________
Swig maillist - Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig
