Re: Access to C++ dlls from Python

Am 29.10.2010 um 19:06 schrieb bifferos:

>
> --- On Fri, 29/10/10, Diez B. Roggisch <[email protected]> wrote:
>
>> Please reply to the mailing-list, not
>> me personally.
>
> Cheeky monkey!  You emailed *me* personally, so I replied
> personally. :-P
>
> Further, some would consider it bad netiquette to forward a
> personal email to a public list, but never mind about that.

Argl. Sorry for that, blame apple mail. Used to use Thunderbird who  
got it right.

>
> <snip>
>> The compiler-question is potentially an issue if there is a
>> mismatch
>> between the MSVCRT-variants Python and your DLL use, but
>> that's a
>> problem under all circumstances.
>
> You can see from my OP that I don't care.

You can care or don't as much as you want - the libraries (python.dll  
and your.dll) will, *if* they conflict. That's the reason why you can  
compile extensions for Python with mingw (as that can select the  
MSVCRT), but not with a mis-matching VC. At least that was the answer  
given to me the last time I asked why one can't build extensions for  
Python with whatever VC-compiler one wants. It's a *runtime* thing.


>
>> The discussions have taken place on this list, please
>> google them. I
>
> I posted on the list because I couldn't find what I was looking
> for using Google.   Search for what?  C++?  DLL?  Class?
> Enlighten me please.
>
> Most of the Googles I did on the subject ended up on posts where
> someone asked similar questions, and got a barrage of replies
> ahem... explaining that they shouldn't do that.  Well, I want to
> do it, as they say in America 'get over it' :).  I see I've
> inadvertently now added to the list of 'non-answers' out there on
> the Interweb.  Sigh.... :(.


Well, it is surprisingly hard to find. I have it located in my inbox,  
but can't find the discussions somewhere online.

This is one thing that is related:

  http://pygccxml.svn.sourceforge.net/viewvc/pygccxml?view=revision

Other keywords to google: cpptypes.

Time-range in this archive is January 2009. You can download the  
archives by month I think.

>
>> can't comment on the state of affairs there, but in all
>> honesty:
>> creating a patched + proprietary version of ctypes is *way*
>> more
>> effort that to create C++ extension.
>
> I wasn't really asking about which way is least effort, sorry if
> you misunderstood.
>
>> ctypes-C++ support would only be useful if it would work
>> the same way
>> as ctypes does - seamless, without the need to invoke a
>> compiler. It
>
> Here we agree.
>
>> doesn't, and it seems to be a problem that's pretty hard.
>
> I know nothing about ctypes-C++, but if it works by using a
> compiler, it's not what I'm after.
>
> Hard?  Not for anyone doing any reverse-engineering of C++ code,
> so it seems.
>

Well, here we disagree. Cross-platform issues aside, my thinking is  
this: C++ is hard because you essentially have to be a compiler to  
know how to generate ABI-conformant code. And this is especially the  
case if you add templates to the mix.

You can certainly reverse-engineer & cobble something together that  
works for that special subset of problems your DLL.

And because it sounded as if that's what you cared about, I thought  
you wanted the simplest solution. Which IMHO still is a wrapper. It  
works, because it uses a compiler - which obviously knows, what it's  
doing :)

But if you want to solve the general problem - well, my best wishes to  
you, I will certainly love to see that happen + use the results. But  
forgive me for being sceptical.


>> If you don't want to go down the C++-wrapper route, you
>> might consider
>> wrtiting a simple C-API-wrapper that can be loaded using
>> ctypes. That
>> however depends how high the trade-off between wrapping by
>> hand and
>> generating is. The richer the C++-interface, the more you
>> should check
>> out SIP.
>
> Python is for many people a prototyping language.  It leads to
> other things.  This means once I've understood the principles
> in Python, I can then move on to similar implementations in
> other languages, including compiled ones.
>
> I do not want to write a wrapper.  I want to use Python to
> interact at the ABI level.
>
> I think all I need at the moment is a rather limited
> CALL_WITH_THIS(method, this, *args) type of function.
>
> e.g.:
>
> class MyVTable(Structure):
>  _fields_ = [("Print", CFUNCTYPE(None, c_char_p))]
>
> class MyClass(Structure):
>  _fields_ = [("vtable", POINTER(MyVtable))]
>
> dll = cdll.LoadLibrary("mydll.dll")
> dll.GetObject.restype = POINTER(MyClass)
> obj = dll.GetObject()
> CALL_WITH_THIS(obj.contents.vtable.contents.Print, obj, "Hello World")
>
> NB:  This might not even be valid ctypes code, I'm just typing it
> from memory, so don't pick it apart too much, just an example.

The above mentioned project might be able to do just that.

Good luck + sorry again for the lecturing about netiquette. My bad.

Diez

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev