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): a) Introduce syntax for declaring external C++ classes. Such classes can only be used as pointers; and can be heap-allocated through new cython.new/cython.delete magic functions. b) Add support for this, using the non-pointer syntax for the type: cdef cpp.std.vectot[int] vec = cpp.std.vectot[int](4) # construct ... vec = something_else # destruct This requires reference counting the C++ class. This would result in a Pythonic feel. c) Use flow control analysis/live variable analysis to optimize b) and allocate the variables that can on the stack while preserving the same semantics. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
