On Jun 26, 2009, at 10:42 PM, Stefan Behnel wrote:

> Hi,
>
> Danilo Freitas wrote:
>> To let people know better here, the syntax for defining C++  
>> classes is
>> (using an example file for tests):
>>
>> cdef extern from "foo.h" namespace something: #namespace is optional
>
> I would prefer seeing from that header line that this block deals  
> with C++.
> Enforcing that wouldn't hurt users, but improve readability, and  
> make it
> easier to expand the block content to potential future syntax  
> extensions
> that aren't allowed for C definitions.

I'm not sure what the gain is here. Either the whole file is C++, or  
it's not. (For instance, the new operator would be invalid anywhere  
in the file if it's not C++). You don't have some blocks that are and  
some blocks that are not.

>
>
>>     cdef cppclass Foo:
>>         int do_something(int)
>
> Fine with me, but what about overloaded signatures? That also  
> impacts the
> constructor.

We will support them just as we support overloaded methods.

>>     cdef Foo *make_Foo():
>>         pass
>>
>>     cdef Foo2 *make_Foo2()
>
> Would that be a regular factory function or a way to write the  
> constructor?

Those are just functions for testing C++ class manipulation before  
constructor syntax had been settled on. (Of course, they're perfectly  
valid as factory functions as written.)

>> Also, objects declared inside a C++ class are taken as C types  
>> (Python
>> objects not allowed)
>
> Why not? They'd map to a PyObject*, which Cython code would ref- 
> count its
> access to. If you change it from C++ code, you'd just be on your  
> own, as
> usual. Same for the C++ destructor, which Cython won't generate for  
> you.
> Call it an advanced feature.


We are not defining C++ classes here, just declaring externally- 
defined classes. It is unclear what the semantics of an object member  
would be. Would it there be a guarantee that it is set to a non-NULL  
increfed value on construction? Does the dectructor have a contract  
to decref it? It's probably better to require a specific cast here to  
signal from this point on refcounting has to be done manually (either  
by the user, or by the C++ library author).

I'm not opposed to methods that take/return objects (e.g. when a new  
reference is returned, it should be an object), as there's no  
"lifetime" to worry about.

- Robert

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

Reply via email to