Robert wrote: > On May 7, 2009, at 2:03 AM, Dag Sverre Seljebotn wrote: > >>> 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. > > I hadn't seen your retraction of "also changes b" so I thought you > were trying to pass things around by reference. Then what does
That whole explanation was a mess, as my daughter waked up from her sleep at the time before I could improve it :-) > b = a > > actually do? Construct a new Python object, then copy by value into > it, and assign to be? So > > a is b > > is now False? I'll just forget about earlier explanations. But what I am advocating is to just have a regular Python reference transfer, no C++ operators involved. With that approach, cdef CppObject a += 2 would mean the same as a = CppObject(a + 2) i.e. a new Python wrapper passing in a+2 as the argument. (C++ classes almost always has this "copy constructor", or else they can't be passed by value in the first place anyway). I am agreeing with Stefan that this is probably orthogonal. It is something you might want to support for C structs as well, so that cdef CWidget a, b b = a a.show_caption = True # also changes b would hold, i.e. an ability to give C structs Python semantics. This would especially be useful given the recent method-on-struct idea, as b = a a.set_value(3) # does not modify b is a "new" wierd exception from Python semantics. I still believe it should be discussed now because a) it heavily impacts how one thinks about C++ operators b) it is a way to solve the construction/destruction problem with C++ classes but as a feature, it could be mostly orthogonal. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
