On May 7, 2009, at 2:14 AM, Stefan Behnel wrote: > Dag Sverre Seljebotn wrote: >>> Dag Sverre Seljebotn wrote: >>>> 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 >>> >>> That wouldn't work, though. Imagine you'd return the C++ object >>> pointer >>> from a function. What would happen to the Python object that >>> holds it? >>> How would you keep the ref-counting context for it? >> >> There would be no coercion between pointers and refcounted >> variables. I.e. >> if you have >> >> cdef extern CppObject* foo() >> >> you can NOT do >> >> cdef CppObject obj = foo() >> >> It would only work when C++ returned an object *by value*: >> >> cdef extern CppObject foo() >> cdef CppObject obj = foo() >> >> This would then heap-allocate a CppObject, passing in the object >> that is >> returned to the copy constructor. > > Ah, ok, got it. So they'd basically be distinct types and you cannot > (implicitly) coerce a C++ object to a pointer. That should work then.
Will dereferencing a CppObject pointer always create a Python object then? You could take the address of a CppObject and get a volitile pointer (just as with bytes -> char*), right? > Can C++ objects override their own allocation, or could you use a > PyVarObject to allocate both the object and the Cython wrapper at > once? Yes, you can, we do that in Sage. I don't think one can declare a struct member to be an object without a no-args constructor without extra work though, so one would have to do the same hackery that was proposed for stack-allocated objects. > (targeting heap allocation here, I assume that stack allocated > objects do > not need ref-counting anyway?) Yep, stack-allocated objects disappear with the stack. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
