Robert Bradshaw wrote:
> 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.
Good point. That's actually fairly tricky to do if the class doesn't
have a no-arg constructor. If you have this:
class MyClass {
MyClass(int x) {...} // non-empty constructor
};
Then in order to use it in a struct (without going through a pointer)
one would actually have to do this:
struct foo {
MyClass myinstance;
public:
foo() : myinstance(any expression in globals) {}
// or: foo(x,y,z) : myinstance(any expression in x,y,z,globals) {}
}
Getting Cython output code like this is non-trivial, at least without
directly copying the member-construction-syntax of C++.
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
