[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    Re: [PyKDE] SIP questions
From:       Phil Thompson <phil () river-bank ! demon ! co ! uk>
Date:       2003-04-02 7:14:19
[Download RAW message or body]

On Wednesday 02 April 2003 4:09 am, Claus, Richard wrote:
> I have used SIP to provide Python access to a set of C++ classes I wrote. 
> These classes don't involve either PyQt or Qt.
>
> A few points:
> 1) I have a placement operator new(size_t sz, void* p, bool swap) in one of
> the classes.  It is used internally to the C++ code and is not exposed to
> Python.  When the SIP-generated code is compiled by VS.NET, it complains
> about the lack of existance of the standard new operator in the code
> generated for the class constructors, although it has no problem finding it
> for classes not having additional operator news defined.  I would have
> thought that it should be able to figure out which new to use from the
> signature.  I saw two solutions: 1) Provide a new operator in my class that
> has the behaviour of the standard one, or 2) use the scoping operator (i.e.
> ::new MyClass) in %MemberCode.  I had to handle the delete operator
> similarly.  What's the right thing to do?  Should SIP be using the scoping
> operator in the generated code?

I think solution 2 is the most appropriate one. I don't want SIP to become 
overly complex by being able to handle every possible C++ scenario - so long 
as the problem can be overcome with handwritten code. If it can be shown that 
the same requirement for handwritten code occurs frequently, then I'm happy 
to automate it.

> 2) Some of my C++ classes have pure virtual functions.  The SIP generated
> code looks like: int sipMyDatagramIterator::process(MyDatagram * a0)
> {
> 	if
> (sipIsPyMethod(&sipPyMethods[0],sipPyThis,sipName_PKG_MyDatagramIterator,si
>pName_PKG_process)) return
> sipMyDatagramIterator::sipVH_process(&sipPyMethods[0],sipPyThis,a0); }
>
> about which VS.NET rightfully complains:
> c:\pkg\sippkgmydatagramiterator.cpp(61) : warning C4715:
> 'sipMyDatagramIterator::process' : not all control paths return a value
>
> I tried copying this and adding an else clause in %MemberCode, but it
> didn't work.  I don't remember why.

SIP doesn't allow you to instrument that particular part of generated code.

SIP v4 generates different code that doesn't generate the warning.

> 3) I'm concerned about speed.  I'd like certain class methods to provide
> access to Numeric or NumArray style arrays, but haven't figured out how to
> do that yet.  In the mean time, I am trying to avoid a copy by returning
> PyBuffer_* in %MemberCode instead of PyString_*.  However, this leads to
> wanting to pass PyBuffers into the C++ code and I haven't managed to figure
> out how to tell sipParseArgs to accept them.  Any suggestions?

Look at %MappedTypes. This effectively allows you to define any (real or fake) 
C++ type to SIP and provide the code necessary to convert between Python and 
"native" formats. Normally "native" is C++ - but it could also be Python and 
the conversions effectively be no-ops.

> Finally, I've fallen into trouble with Python's garbage collection in that 
> when I use my code in a multithreaded environment, Python sometimes exits
> with a complaint about finding an object on its GC list that has already
> been collected (currently not so easy to reproduce, so I don't have an
> exact copy of the error message).  Given that SIP handles reference
> counting, can anyone give me some suggestions for going after this?  The
> placement new on an existing Python string trick is little more than
> casting to give the string a personality.  Maybe this is confusing SIP
> somehow?

Is your handwritten code dealing with threads properly, eg. using the 
Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS macros?

Phil

_______________________________________________
PyKDE mailing list    PyKDE@mats.gmd.de
http://mats.gmd.de/mailman/listinfo/pykde
[prev in list] [next in list] [prev in thread] [next in thread]