On May 7, 2009, at 12:24 AM, Dag Sverre Seljebotn wrote:

> Robert Bradshaw wrote:
>> On May 6, 2009, at 10:06 PM, Dag Sverre Seljebotn wrote:
>>
>>> Robert Bradshaw wrote:
>>>> On May 6, 2009, at 1:33 PM, Dag Sverre Seljebotn wrote:
>>>>> OTOH, if heap-allocation-and-refcounted semantics isn't selected,
>>>>> one
>>>>> should use "cdef struct" instead, like Lisandro suggests.
>>>> Structs are also something different (well, there's a lot of
>>>> similarity, but the idea of inheritance is a big one),  
>>>> especially if
>>>> we're looking at heap allocated classes for the first iteration. (I
>>>> don't think we want to try to do our own refcounting, let the user
>>>> use new and delete directly if they want to use C++.)
>>> Well, they are not something different in C++ :-)
>>
>> A C++ class is a glorified struct, but one still has plain old
>> structs too.
>
> ...which is the same as a class with only public fields in them :-)
>
> What I'm getting here at is that we are creating a distinction in  
> Cython
> which actually does not exist in C++ (rather C++ adds member methods,
> constructors, private members, and vtables all as orthogonal and
> independent extensions).
>
> But I think that is how it should be.

Yep, if C++ considers them different enough to allocate two separate  
keywords for them, than so should we. (I think it'll also be less  
confusing).

>>> If you don't want to try your own refcounting, please, please tell
>>> me that
>>> the only allowed form of usage of the class will be
>>>
>>> cdef CppClass* obj
>>
>> This is what I imagined (for now at least).
>>
>>> Allowing
>>>
>>> cdef CppClass obj
>>>
>>> in any form and requiring a manual delete would be very confusing  
>>> and
>>> difficult to remember.
>>>
>>> (That's what I mean by refcounting -- I imagined the difference
>>> between
>>> these two syntaxes would be that the latter of these would be
>>> refcounted;
>>> and subject for automatic stack-allocation-optimization.)
>>
>> By "refcounting", are you implying global garbage collection of some
>> sort, just like Python objects, or something that emulates being on
>> the stack (e.g. objects are deleted when the scope exits, and all
>> assignments are done by value)?
>
> I was referring to something which have the full semantics of Python
> objects (after the result of the "New idea for C++ stack allocation"
> thread, which expored the opposite idea).
>
> So
>
> cdef CppClass obj = None
> obj.do_something() # Illegal, it is None
> obj = CppClass(3)
> obj.do_something() # OK
>
> ...and so on, just like cdef classes.
>
> Then stack allocation would be a pure transparent optimization (an
> important one; you don't really want to be heap-allocating STL  
> iterators
> for each iteration!) where semantics can be preserved.

I agree it makes stuff like STL iterators nice to work with, but can  
one do

cdef CppClass x():
     obj = CppClass(3)
     return obj

Or will it be freed on exit unlike a Python object? Also, what about

def y():
     cdef CppClass a = CppClass(5)
     cdef CppClass b = a
     return # don't free a twice...

Or perhaps you're thinking about wrapping C++ class instances inside  
actual objects?

- Robert

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

Reply via email to