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).
This is, BTW, a good reason why I proposed calling operators by
"rewrapping" them, because then
a = vec.begin()
b = a
a.next() # also changes b, through calling a++
makes perfect sense!
I'm happy that only "CppClass*" will be allowed at first, which takes much
of this worry away. However note that this might have consequences for how
operators should be defined (I haven't seen a concrete proposal for what
you are thinking there so I don't know how it would fare).
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
