On May 7, 2009, at 12:58 AM, Dag Sverre Seljebotn wrote:
> 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;
> };
I agree it's a tiny distinction, but it *was* enough to convince the
authors of C++ that a new keyword was warranted.
> 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.
Hmm... I've been thinking of structs as plain old dumb C structs, as
they always have been in Cython, and classes as the C++ version with
all the goodies like inheritance, polymorphism, operator overloading,
etc.
BTW, Not ruling out stack/automanaged memory management down the road.
>> Or perhaps you're thinking about wrapping C++ class instances inside
>> actual objects?
>
> Yes!
OK, that changes everything. It still has its issues though. I'd
assume you'd try to delete the C++ object on deallocation? But what
if two distinct Python objects refer to the same C++ object? Or the C+
+ object (pointer) gets passed and stored in some library somewhere?
I don't see a way to ensure a one-to-one relationship between C++
objects and Python objects--short of having stack allocated semantics
(i.e. it goes out of scope and is deconstructed when the function
exits) I don't see how one can automatically refcount C++ classes.
> 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.
You know people are then going to want to have access to all it's
methods and members, so that just declaring the C++ class will be
creating a full-fledged wrapper around it. I can just see the
expectations now :).
[...]
> I'm happy that only "CppClass*" will be allowed at first, which
> takes much
> of this worry away.
One drawback is that it makes not having a good referencing operator
a pain. One will have to write a lot of code like
c[0] = a[0] + b[0] * c[0]
Cython does automatically promote a.b to a->b when a is a pointer
type, and it'd be really nice to do something similar, but, e.g.,
CppClass* + int already has meaning.
> 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).
http://www.mail-archive.com/[email protected]/msg05140.html
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
