On Apr 3, 2009, at 12:31 AM, 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.
+1 > 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. Note that the allocate-on-the-stack is not specific to just stacks. For example, it is possible to define a C++ class as a member of a cdef class, and then its memory is allocated along with the object as part of the struct. Currently, one then has to actually initialize and destroy manually. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
