The SWIG documentation is pretty detailed - <a href="http://www.swig.org/Doc1.3/Sections.html">http://www.swig.org/Doc1.3/Sections.html</a><br><div>SWIG has  a concept of pointer ownership which it uses to manager pointers.</div>
<div>The interface files contain the C function declarations and variable declarations. The wrapper function generated is the &#39;glue&#39; between the scripting language and the underlying C function.</div><div><br></div>
<div>Only concern is there may be some &#39;code bloat&#39;</div><div><br></div><div>--Bhaskar.</div><div><br></div><div><br></div><div><br></div><div class="gmail_quote">On Tue, Sep 15, 2009 at 8:26 AM, bhaskar jain <span dir="ltr">&lt;<a href="mailto:bhaskar.jain2002@gmail.com">bhaskar.jain2002@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>Thanks for the response.<br></div><div><br></div><div>What i faced was intentionally passing unexpected/nonsense data cause segmentation fault in one case. Was wondering if this is because of SWIG or because of the underlying library (which in turn uses glib). But the underlying library looks ok. Have you faced such issues while working with SWIG. Is it reliable to be used in production level code which will be pretty load intensive.</div>

<div><br></div><div>Also who frees the pointers in case of python binding? Some functions say the caller should free the pointer but in case of python binding  does the python memory manager frees it using the standard reference count.</div>

<div><br></div><div>I believed the interface file (.i file) has to be hand-written. Can you please elaborate on the Makefile approach.</div><div><br></div><font color="#888888"><div>--Bhaskar.</div></font><div><div class="h5">
<div><br></div><div><br></div><div><br></div>
<div><br></div><br><div class="gmail_quote">On Tue, Sep 15, 2009 at 12:25 AM, Gora Mohanty <span dir="ltr">&lt;<a href="mailto:gora@srijan.in" target="_blank">gora@srijan.in</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On Tue, 15 Sep 2009 00:04:01 +0530<br>
bhaskar jain &lt;<a href="mailto:bhaskar.jain2002@gmail.com" target="_blank">bhaskar.jain2002@gmail.com</a>&gt; wrote:<br>
[...]<br>
<div>&gt; Problem is that there was a bug and they have changed a few lines<br>
&gt; in one of the C files. So my question is - will just applying the<br>
&gt; patch and installing the library again, will i get a fresh good<br>
&gt; python binding or do i need to regenerate the wrapper_ *.c files<br>
&gt; using SWIG.<br>
<br>
</div>It depends on what was changed, but it is best to regenerate<br>
everything. Is this that much of a concern in terms of time,<br>
etc. It is quite easy to set up a Makefile to do this.<br>
<div><br>
&gt; Any tips in working with SWIG, using the python bindings will be<br>
&gt; appreciated. Also is it a frequent problem of segmentation faults<br>
&gt; using the python bindings of C programs which employ lot of<br>
&gt; pointers. Sorry, I am new to SWIG.<br>
&gt;<br>
&gt; Is it advisable to use SWIG at all?<br>
</div>[...]<br>
<br>
I would enthusiastically advocate SWIG, but have had arguments with<br>
people who take a different view, and whose opinions I respect. The<br>
best counter-arguments I have heard is cleanness of the generated<br>
code, and efficiency, but at least for a non-pedal-to-the-metal<br>
coder like me, SWIG definitely does the job. So, I would say that<br>
if you can take a look at the generated SWIG code, and think that<br>
you can do better, please do that, and contribute your approach<br>
back to SWIG.<br>
<br>
Regards,<br>
Gora<br>
_______________________________________________<br>
BangPypers mailing list<br>
<a href="mailto:BangPypers@python.org" target="_blank">BangPypers@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/bangpypers" target="_blank">http://mail.python.org/mailman/listinfo/bangpypers</a><br>
</blockquote></div><br>
</div></div></blockquote></div><br>