> Robert Bradshaw wrote:
>> On May 7, 2009, at 12:24 AM, Dag Sverre Seljebotn wrote:
>>> 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).
>
> But C++ doesn't!!
>
> class Foo {
> int x;
> public:
> int y;
> void z();
> };
>
> is EXACTLY the same as
>
> struct Foo {
> int y;
> void z()
> private:
> int x;
> };
>
> Whatever the distinction is supposed to be in Cython, it cannot be the
> default private/public, as only the public stuff is available to us
> anyway!
>
> I've been using the distinction to mean "these structs should be
> reference-counted, not have stack-allocated semantics like we use for C
> structs". If one doesn't plan to ever go for a reference counted scheme,
> we should just use plain struct.
>
>>>>> 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?
>
> Yes! Allocation would happen through an actual (as light-weight as
> possible, and probably mostly opaque, perhaps doing as much as printing
> the C++ name of the class in its repr) Python object; and assigning it to
> "cdef CppClass a" would basically make Cython automatically do all
> accesses (except passing around references) on the contained pointer.
>
> Again -- this is a larger debate with huge consequences for how one should
> do operator overloading etc. For instance, += would have to be implemented
> like
>
> it += 1
>
> would mean
>
> it = please_refcount_iteratorclassname(new std::vector::iterator<int>(it +
> 1))
>
> However, this kind of semantics ensures that we avoid that
>
> cdef vector[int].iterator a, b
> a = vec.begin()
> b = a
> a += 1 # also changes b
>
> which seems to be the alternative (where a and b are just kept on the
> stack and we somehow circumvent the constructor business).
Sorry, it's too early in the morning :-) please disregard this last bit,
it doesn't make sense .. "b = a" make a copy if stack-allocation, which
makes sure that "a += 1" only modifies a.
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
