object ownership and containers

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

object ownership and containers

P. Oscar Boykin
Hello,

I have read the swig docs at:  http://www.swig.org/Doc1.3/ but I guess I missed the part on how to handle containers of pointers.

What I would like, is the "opposite" of %newobject.  Such, that when I call a method inserting a pointer into a container, I can tell swig to stop reference counting that pointer.  Something like:

class Container {

  void add(char* key, Object* o);
  Object* remove(char* key);

};


So, I want swig to tell swig to drop ownership of the object when I call add, and regain ownership when I call remove.  I think that %newobject can handle the remove case, but I see nothing to handle the add case.

One obvious approach is to make a wrapper for the add method, which (in python) sets o.thisown = 0, when the object is added and o.thisown = 1 when it is removed.  However, I would prefer a way to specify this in swig's definition language so it works properly in all wrapped languages.

Am I missing something?  Is there a better way to handle this case without changing the C++ code?

Best Regards,
--
P. Oscar Boykin                            http://boykin.acis.ufl.edu
Assistant Professor, Department of Electrical and Computer Engineering
University of Florida
Reply | Threaded
Open this post in threaded view
|

Re: object ownership and containers

Marcelo Matus
In the swig CVS version you have now

%delobject

which is the inverse of %newobject and it does what you are looking for.

Marcelo


P. Oscar Boykin wrote:

> Hello,
>
> I have read the swig docs at:  http://www.swig.org/Doc1.3/ but I guess
> I missed the part on how to handle containers of pointers.
>
> What I would like, is the "opposite" of %newobject.  Such, that when I
> call a method inserting a pointer into a container, I can tell swig to
> stop reference counting that pointer.  Something like:
>
> class Container {
>
>   void add(char* key, Object* o);
>   Object* remove(char* key);
>
> };
>
>
> So, I want swig to tell swig to drop ownership of the object when I
> call add, and regain ownership when I call remove.  I think that
> %newobject can handle the remove case, but I see nothing to handle the
> add case.
>
> One obvious approach is to make a wrapper for the add method, which
> (in python) sets o.thisown = 0, when the object is added and o.thisown
> = 1 when it is removed.  However, I would prefer a way to specify this
> in swig's definition language so it works properly in all wrapped
> languages.
>
> Am I missing something?  Is there a better way to handle this case
> without changing the C++ code?
>
> Best Regards,
> --
> P. Oscar Boykin                            http://boykin.acis.ufl.edu 
> <http://boykin.acis.ufl.edu>
> Assistant Professor, Department of Electrical and Computer Engineering
> University of Florida




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Reply | Threaded
Open this post in threaded view
|

Re: object ownership and containers

Charlie Savage
There is also the DISOWN typemap which applies to specific types passed
in to a method (there is an example of usage in the Ruby documentation
and in a couple of other places in the manual).

Marcelo, is %delobject a %feature like %newobj while DISOWN is a
typemap?  Does that mean you its easier to use %delobject when a method
takes just one parameter, but you have to use DISOWN when it takes
multiple parameters and only frees one of them?

Just curious how you see these two features relate.

Charlie

Charlie

Marcelo Matus wrote:

> In the swig CVS version you have now
>
> %delobject
>
> which is the inverse of %newobject and it does what you are looking for.
>
> Marcelo
>
>
> P. Oscar Boykin wrote:
>
>> Hello,
>>
>> I have read the swig docs at:  http://www.swig.org/Doc1.3/ but I
>> guess I missed the part on how to handle containers of pointers.
>>
>> What I would like, is the "opposite" of %newobject.  Such, that when
>> I call a method inserting a pointer into a container, I can tell swig
>> to stop reference counting that pointer.  Something like:
>>
>> class Container {
>>
>>   void add(char* key, Object* o);
>>   Object* remove(char* key);
>>
>> };
>>
>>
>> So, I want swig to tell swig to drop ownership of the object when I
>> call add, and regain ownership when I call remove.  I think that
>> %newobject can handle the remove case, but I see nothing to handle
>> the add case.
>>
>> One obvious approach is to make a wrapper for the add method, which
>> (in python) sets o.thisown = 0, when the object is added and
>> o.thisown = 1 when it is removed.  However, I would prefer a way to
>> specify this in swig's definition language so it works properly in
>> all wrapped languages.
>>
>> Am I missing something?  Is there a better way to handle this case
>> without changing the C++ code?
>>
>> Best Regards,
>> --
>> P. Oscar Boykin                            http://boykin.acis.ufl.edu 
>> <http://boykin.acis.ufl.edu>
>> Assistant Professor, Department of Electrical and Computer Engineering
>> University of Florida
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Swig-user mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/swig-user
>
>

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: object ownership and containers

Marcelo Matus


Charlie Savage wrote:

> There is also the DISOWN typemap which applies to specific types
> passed in to a method (there is an example of usage in the Ruby
> documentation and in a couple of other places in the manual).
>
> Marcelo, is %delobject a %feature like %newobj while DISOWN is a
> typemap?  Does that mean you its easier to use %delobject when a
> method takes just one parameter, but you have to use DISOWN when it
> takes multiple parameters and only frees one of them?


yes, exactly, DISOWN is parameter oriented while %delobject is method
oriented, but they do
the same, %delobject marks the first parameter in the given method to be
disowned.
%delobject is just more natural and in some sense more robust since it
doens't depend
on the parameter name, and therefore it can't be applied by accident to
another parameter.

Marcelo



>
> Just curious how you see these two features relate.
>
> Charlie
>
> Charlie
>
> Marcelo Matus wrote:
>
>> In the swig CVS version you have now
>>
>> %delobject
>>
>> which is the inverse of %newobject and it does what you are looking for.
>>
>> Marcelo
>>
>>
>> P. Oscar Boykin wrote:
>>
>>> Hello,
>>>
>>> I have read the swig docs at:  http://www.swig.org/Doc1.3/ but I
>>> guess I missed the part on how to handle containers of pointers.
>>>
>>> What I would like, is the "opposite" of %newobject.  Such, that when
>>> I call a method inserting a pointer into a container, I can tell
>>> swig to stop reference counting that pointer.  Something like:
>>>
>>> class Container {
>>>
>>>   void add(char* key, Object* o);
>>>   Object* remove(char* key);
>>>
>>> };
>>>
>>>
>>> So, I want swig to tell swig to drop ownership of the object when I
>>> call add, and regain ownership when I call remove.  I think that
>>> %newobject can handle the remove case, but I see nothing to handle
>>> the add case.
>>>
>>> One obvious approach is to make a wrapper for the add method, which
>>> (in python) sets o.thisown = 0, when the object is added and
>>> o.thisown = 1 when it is removed.  However, I would prefer a way to
>>> specify this in swig's definition language so it works properly in
>>> all wrapped languages.
>>>
>>> Am I missing something?  Is there a better way to handle this case
>>> without changing the C++ code?
>>>
>>> Best Regards,
>>> --
>>> P. Oscar Boykin                            
>>> http://boykin.acis.ufl.edu <http://boykin.acis.ufl.edu>
>>> Assistant Professor, Department of Electrical and Computer Engineering
>>> University of Florida
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through
>> log files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>> _______________________________________________
>> Swig-user mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/swig-user
>>
>>



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user