Dag Sverre Seljebotn wrote:
> Danilo Freitas wrote:
>> Hi, all.
>>
>> I just wrote a proposal for GSoC, and I'm posting it here to hav
>> feedbacks about it.
>>
>> Here is the link with the wiki with my proposal:
>> http://wiki.cython.org/gsoc09/daniloaf
> 
> Hi! Here's some feedback (these are my opinion only and not necesarrily of
> others here). As Robert says though, please apply *now* and we can talk
> about and edit the application later.
> 
> I wrote some notes a year ago on http://wiki.cython.org/enhancements/cpp ,
> you could have a look (thopugh they are outdated).
> 
> Anyway, I see such a project as a) identifying and b) solving a number of
> trouble spots for C++ users. Here's my list. I suppose not all of this
> would have to be in a gsoc, it's just some feedback for consideration.
> 
> 1) Using templates -- you already have this. My preferred syntax is using
> [] BTW. As Robert said, it should support any template and not only STL.
> 
> 2) Operator overloading -- you already have this as well. This should be
> made generic, so that all C++ operators which have a corresponding Cython
> operator can be used on a type.
> 
> 3) References. Currently there's a problem (I didn't actually try this,
> just assuming this from how I know things work):
> 
> If you make this C++ function:
> 
> void incargs(int& a, int& b) { a++; b++; }
> 
> then it has to be declared in Cython like this:
> 
> cdef extern void incargs(int a, int b)
> 
> and a call like this would result in:
> 
> cdef int a = 3
> cdef object b = 3
> incargs(a, b)
> # now a is 4 and b is 3 !!!
> 
> My preferred solution for this dilemma would be to declare C++ references
> Cython-side and require pointers to be passed (which are then dereferenced
> prior to the call), because that's consistent with Cython semantics. I
> find it too confusing syntax-wise that "a" above can change value in
> Cython.
> 
> 4) Calling constructors/destructors.
> 
> This is an interesting problem. C++ supports both stack and heap
> allocation, while Cython/Python (and e.g. Java) only supports heap
> allocation (of objects with constructors/destructors).
> 
> For instance, one cannot do this in Cython currently: Instead I would have
> this 3-step plan (of which perhaps only the first one is gsoc):

Something fell out here, sorry about that. Here it is:

For instance, one cannot do this in Cython currently:

cdef my_std_vector_int_iterator it = myvec.begin()

because an STL iterator cannot be constructed without arguments, and 
when that code is Cythonized, it roughly ends up like this:

my_std_vector_int_iterator it; # all declarations at top
...
it = myvec.begin()

(Note that assignment-on-declaration is the same as passing constructor 
arguments in C++).

One solution would be to add a syntax for stack allocation, however that 
interferes with lots of Python rules (variable scoping for instance).

So instead I would have this 3-step plan [...]


-- 
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to