[python-win32] RE: C extension class wrapping and
sequence questions [Jens]
Jens B. Jorgensen
jens.jorgensen at tallan.com
Tue Dec 9 15:55:30 EST 2003
Sounds like your approach will make the most sense right now. For a
first go at building a python wrapper extension you definitely chose an
involved one! The stuff I've done has all followed the model where the
Python object owns the underlying struct (and they've all been pretty
simple no-logic structs). However when the library your working with
already has a model where C++ objects own subordinate objects and
control their lifetimes things get significantly more complicated as
you've surmised. To make things really work correctly you almost need a
kind of bi-directional relationship where the C++ objects can own the
objects they contain but when destroy objects they may need to twiddle
some Python wrapper construct.
class HybridContainer
{
public:
std::vector<ShapeA *> a_shapes;
std::vector<ShapeB *> b_shapes;
void empty() {
/* delete each object in a_shapes, b_shapes and empty the
collections */
}
};
So in the above class when empty() is called it is possible that we've
got a Python wrapper object around one of the ShapeAs or ShapeBs that
still has a reference. This would be a big problem! There are lots of
different solutions some more or less intrusive on the C++ code.
Certainly an interesting set of problems.
Mark English wrote:
>RE: Jens' message
>I'll bang on about this a bit more...
>
>
>>>If you have some system that auto-generates C++ how hard would it be
>>>
>>>
>to
>
>
>>>get that same code to generate a Python extension written in C++?
>>>
>>>
>This
>
>
>>>might be the best solution of all!
>>>
>>>
>The data part is autogenerated. I want to be able to build that up in
>Python, then pass the relatively unintelligent structures built in
>Python to C++ code that can make use of them. I can only autogenerate
>the message/record structures, but the good news is that they're
>relatively unintelligent. Just a series of structs with some C++ on top
>(get/set methods etc.), some containing instances of others.
>
>I agree with your analysis, and I'm currently looking into the thin
>Python wrapper approach, where the Python instances just bolt on top of
>a C++ pointer (although typically they will own the lifetime of the C++
>pointer - at least for now). Much like the CWnd wrappers in win32ui.
>I thought about using the sequence methods you mentioned, but I'm also
>looking into using the new subtyping introduced in 2.2. Need to find a
>tutorial/example for this...
>
>Unfortunately this is a side project and the learning curve is a little
>steep, but it looks like I can subclass the python sequence type, and
>possibly add some additional processing to get some of the functionality
>I want.
>
>Ultimately, however, the "owned array" or whatever you want to call it
>may be a flawed (and therefore floored) idea. For example, if the array
>sets its members by actually calling set methods in the owning message
>it solves this problem:
>
>
>>rec = PyRecords.Record()
>>msg = PyMessages.MessageFoo()
>>msg.arrayRec[2] = rec # Will actually delegate to "msg.SetRec(2, rec)"
>>
>>
>
>I should have explained that some messages contain a fixed size array,
>and an accompanying integer member saying how many elements of the array
>are being used. E.g.
>
>
>>msg.nRecs = 3 #Set the number of elements in the array being used by
>>
>>
>this message
>
>In other words, the C-code may restrict the array size to a fixed
>maximum (e.g. 16), but at runtime the user can say they're only using
>the first 3 elements of the array. Not pretty, but that's what there is.
>Even further trickery would be required around the issue of ownership if
>users wanted to do this:
>
>
>>msg2 = PyMessages.MessageFoo()
>>msg2.arrayRec = msg.arrayRef #Hmmmm
>>
>>
>
>This last line would require a deep (sort of) copy of N elements of the
>array, where N is the known total possible size of the array, or
>preferably the run-time established number of array elements actually
>being used. So I'll have to store the length being used (or at least
>where to look it up) in the array wrapping class (in some cases). The
>auto-generating parser knows where to look all this up, but it gets more
>complex and unwieldy.
>
>All I really wanted to show with all this is that the more I try to
>introduce indirection and issues of ownership into a pseudo-sequence
>class, the harder things become. The sort of thing that would be more
>easily solved in Python than C I suspect...
>
>Cheers,
>mE
>
>P.S. I do appreciate the feedback though. It's an interesting problem
>for a newbie like me
>
>
>-----------------------------------------------------------------------
>The information contained in this e-mail is confidential and solely
>for the intended addressee(s). Unauthorised reproduction, disclosure,
>modification, and/or distribution of this email may be unlawful. If you
>have received this email in error, please notify the sender immediately
>and delete it from your system. The views expressed in this message
>do not necessarily reflect those of LIFFE Holdings Plc or any of its subsidiary companies.
>-----------------------------------------------------------------------
>
>
>_______________________________________________
>Python-win32 mailing list
>Python-win32 at python.org
>http://mail.python.org/mailman/listinfo/python-win32
>
>
--
Jens B. Jorgensen
jens.jorgensen at tallan.com
"With a focused commitment to our clients and our people, we deliver value through customized technology solutions."
More information about the Python-win32
mailing list