[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: SWIG, C++ Exceptions, and Lua
- From: Mark Gossage <mark@...>
- Date: Thu, 27 Mar 2008 02:10:49 +0000 (GMT)
Hello Joey,
Please keep these requests and issues coming in, its all these small bits which I havn't yet added which improve SWIG.
Anyway, the real issue is you want to be able to tell SWIG that certain wrappered functions should take ownership of the object.
I just added the feature for the Lua bindings in SWIG, its known as a DISOWN typemap. (You will need the SVN SWIG to get this).
For your code: you need to specify:
%apply SWIGTYPE *DISOWN {Plot* plot};
before %including. This will inform SWIG that the call to AddPlot() takes ownership of the object. That way when you create a Plot using the constructor, Lua manages the object for you. But when you call AddPlot(), the DISOWN typemap removes Lua's ownership flag. So the object is now owned by C++.
The documentation is not there yet, but the code is. Hope this helps.
PS. There is also a %delobject command which works differently, this may also be useful, see the swig-customisation
documentation for this.
PPS. There is also an example program Examples/lua/owner in SVN which will show you how all this works
Regards,
Mark
<F10681DF-63E2-40DF-95D7-5F9253148EB3@swri.edu>Ok, this is helping, but after debugging further, I actually have a
different, but similar problem.
I have the following code I am wrapping with SWIG:
class Plot {
public:
Plot ();
virtual ~Plot ();
... < other Plot functions >
};
class BoxPlots {
public:
void AddPlot (Plot *plot);
Plot *GetPlot (const unsigned int index) const;
const unsigned int GetNumberOfPlots () const;
};
When I construct my Plot, Lua owns this and that's fine. However,
when I AddPlot to the BoxPlots, now I want to own the pointer. Is
that possible
with SWIG? Alternatively, is there a way with %
newobject to label the constructor as me owning it all. If the user
never AddPlot, I will never see the pointer so the program will leak,
which is why this is worse; but it would keep my program from core
dumping.
Thanks,
Joey
F10681DF-63E2-40DF-95D7-5F9253148EB3@swri.edu>
Sent from Yahoo! Mail.
More Ways to Keep in Touch.