> 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?
All crossings between Cython and C++ would pass the object by value. You'd
still need to use & to get a pointer, which would be similar to str ->
char*.
> 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.
I don't see the problem, sorry.
> 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 :).
Well, obviously that is down the pipeline, but no need to go there now.
I just want *some* way to avoid having to write it[0][0] to dereference an
STL iterator. Everything else is secondary really :-)
> [...]
>
>> 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.
Yes, that's the problem my Python-object-solution was designed to take 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).
>
> http://www.mail-archive.com/[email protected]/msg05140.html
Hmm. So how would e.g. += be treated?
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
