Robert Bradshaw wrote: > which is no better than simply trying to put MyCppClass on the stack, > so sticking the memory chunk in a PyObject* doesn't really save you > anything. (Well, it lets you pass it out of the scope, and gives > reference assignment semantics, but I'm not sure either of these are > desirable for something that looks like its allocated on the stack, > and one could provide this in an orthogonal way (e.g. with the > "managed" keyword idea). Also, giving it reference semantics means > that we could never go and optimize it by placing things actually on > the stack.
We're hitting the core of the matter here! I can see why one would like to stay "close to the metal", so to speak. I was mainly (mis)interpreting your lack of support in the "C++ stack allocation" thread as being in favour of this other proposal... Still, with direct stack allocation one needs a way to do cdef CppObject a, b and then run their constructors before they are used. With structs you can do cdef CObject a a.x = 3 which just doesn't fly with C++ with most classes. My thoughts were in the other thread, but I guess it boils down to making sure that "a" is assigned to before it is used. You are not rejecting that then? That would bring the whole C++ semantics into Cython, so that b = a would invoke operator=, b = a a.set_foo(3) # does not modify b and so on. I guess I don't have to like it to support it, I can see why you'd do it. Keeping "managed" strictly orthogonal does make a lot of sense. -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
