My extension code generator for C++

[Rouslan Korneychuk]

On 07/03/2010 01:54 PM, Thomas Jollans wrote:
> On 07/03/2010 07:22 PM, Rouslan Korneychuk wrote:
>> It's still in the rough, but I wanted to give an update on my C++
>> extension generator. It's available at http://github.com/Rouslan/PyExpose
>
> Question that pops to mind immediately: How does this differentiate
> itself from SWIG? ( I can't say I'm familiar with SWIG, but the question
> had to be posed. )
>

I have never tried swig, but as far as I understand, SWIG uses a layered 
approach where part of the extension is defined C/C++ and that is 
wrapped in Python code. Mine implements the extension completely in C++.

>>
>> The documentation is a little slim right now but there is a
>> comprehensive set of examples in test/test_kompile.py (replace the k
>> with a c. For some reason, if I post this message with the correct name,
>> it doesn't show up). The program takes an input file like
>>
>>   <?xml version="1.0"?>
>>   <module name="modulename" include="vector">
>>       <doc>module doc string</doc>
>>
>>       <class name="DVector" type="std::vector<double>">
>>           <doc>class doc string</doc>
>>           <init overload=""/>
>>           <init overload="size_t,const double&"/>
>>           <property name="size" get="size" set="resize"/>
>>           <def func="push_back"/>
>>           <def name="__sequence__getitem__" func="at"
>> return-semantic="copy"/>
>
> func="operator[]" would also work, I assume?
>
>>           <def name="__sequence__setitem__" assign-to="at"/>
>>       </class>
>>   </module>
>>
>> and generates the code for a Python extension.
>>
>> [snip]
>>
>> I'm really interested in what people think of this little project.
>
> How does it deal with pointers? What if something returns a const
> pointer - is const correctness enforced?
>

When returning pointers or references, you either have to specify a 
conversion explicitly or use the "return-semantic" attribute. The 
current options are "copy", which dereferences the pointer and copies by 
value, and "managed-ref" which is for exposed classes, where the 
returned PyObject stores the value as a reference and holds on to a 
reference-counted pointer to the object the returned the value (there is 
also "self" which has nothing to do with returning pointers. With 
"self", the return value of the wrapped method is ignored and a pointer 
to the class is returned).

I can easily add other options for "return-semantic", such as keeping a 
pointer and deleting it upon destruction. I just implemented the ones I 
need for the thing I'm working on.

As far as returning const pointers and const correctness, I'm not sure 
exactly what you mean. If you mean is there a mechanism to hold on to 
const objects and prevent them form being modified, the answer is no. 
It's not something I need.

> All in all, it looks rather neat.
>
> Thomas

Thanks for the comment.