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.
>> 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.
When interfacing with external code; like with my favourite example:
cdef extern from "vector" namespace std:
cdef cppclass vector[T]:
cdef cppclass iterator:
# next/prev operator overloading somehow,
# we still disagree here I guess
iterator begin()
then when one does
cdef vector[int].iterator it
it = myvec.begin()
it would mean getting hold of
new std::vector<int>::iterator(myvec.begin())
and refcounting it -- however, since begin() returns by value, it would
be legal to instead allocate on stack, as long as semantics are
preserved. (Perhaps just changing this to using placement new and skip
refcounting.)
The alternative to this seems to be the ideas you already rejected. And
I must say I like emulating cdef classes better.
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
