Cpp + Python: static data dynamic initialization in *nix shared lib?
in [Python]
|
Prev: do
Next: zipimport (.pyd & .so) files.
From: sturlamolden on 13 Jul 2010 16:03 On 9 Jul, 17:52, "Alf P. Steinbach /Usenet" <alf.p.steinbach +use...(a)gmail.com> wrote: > For an extension module it seems that Python requires each routine to be defined > as 'extern "C"'. That is strange. PyMethodDef is just a jump table. So why should 'extern "C"' matter? Good luck on re-inventing the wheel (you've probably heared about Swig, SIP, Boost.Python, PyCXX, scipy.weave and Cython...)
From: sturlamolden on 13 Jul 2010 16:06 On 13 Jul, 21:39, "Alf P. Steinbach /Usenet" <alf.p.steinbach +use...(a)gmail.com> wrote: > Thanks! It seems that SCXX does those things that I've been planning to do but > haven't got around to (wrapping standard Python types), while what it doesn't do > (abstracting away all those tables etc. and mapping Python calls to C++ calls) > is what I've been working on. Which could be a Very Nice combination except that > I'm assuming Py3, while SCXX seems to be Py2 only. :-( I'd suggest PyCXX instead. http://cxx.sourceforge.net SCXX is a tiny wrapper mostly used in scipy.weave to inline C++ in Python.
From: Alf P. Steinbach /Usenet on 13 Jul 2010 16:35 * sturlamolden, on 13.07.2010 22:03: > On 9 Jul, 17:52, "Alf P. Steinbach /Usenet"<alf.p.steinbach > +use...(a)gmail.com> wrote: > >> For an extension module it seems that Python requires each routine to be defined >> as 'extern "C"'. > > That is strange. PyMethodDef is just a jump table. So why should > 'extern "C"' matter? Formally because they're incompatible function pointer types. C++98 standard �7.5/1: "Two function types with different language linkages are distinct types even if they are otherwise identical". Add to that �7.5/4 "A linkage-specification shall occur only in namespace scope". And add to that �14-4 "A template, a template explicit specialization, or a class-template partial specialization shall not have C linkage." This means that formally correct code that generates callbacks by templating, is ruled out. In practice, 'extern "C"' matters for the jump tables because for those few compilers if any where it really matters (not just the compiler emitting a warning like reportedly Sun CC does), different linkage can imply different machine code level calling convention. For example, who's responsible for cleaning up the stack, the order in which arguments are pushed or which registers they're passed in, and so forth. Ignoring such matters your code gets into la-la land pretty fast, but, it's a different matter when one /understands/ this and places a requirement on the compiler. > Good luck on re-inventing the wheel (you've probably heared about > Swig, SIP, Boost.Python, PyCXX, scipy.weave and Cython...) Yes, I know Boost.Python in more detail and I've heard of all the rest except SIP, but then regarding SIP I really don't like QT (QT makes eminent sense in the context of Python, they're both essentially dynamically typed, but that means QT is not very nice as C++, plus there is the ugly preprocessor). And as you'd guess if you were not in silly ignoramus assertion-mode, I'm not reinventing the wheel. Cheers & hth., - Alf -- blog at <url: http://alfps.wordpress.com>
From: Dilip on 13 Jul 2010 16:47 On Jul 13, 2:34 am, "Alf P. Steinbach /Usenet" <alf.p.steinbach +use...(a)gmail.com> wrote: > Well, we got no further, but I know of three solutions: > > A) Punting: just say that the compiler has to support C++/C function type > mingling. > -> Perhaps the practical solution, but formally unsafe. > > B) On the script side of things, delegate all calls to single Mother Of All > C func downcaller that supplies as extra arg an id of the C++ function. > -> Micro-level inefficient but easy to use and formally correct. > > C) Let the user define the C linkage function wrappers via macros. > -> Efficient and formally correct but exposes ugly macro names. > > I chose (C). Alf This may or may not be what you are looking for but the middleware Ice provides language mapping to enable Python to call into the Ice libraries which are basically written in C++. You can take a look at this: http://www.zeroc.com/icepy.html However that page may not be very descriptive. The codebase, though, is freely downloadable. You can take a look at it if that will help although you need to wade around a little bit to figure out what is where.
From: sturlamolden on 13 Jul 2010 17:17
On 13 Jul, 22:35, "Alf P. Steinbach /Usenet" <alf.p.steinbach +use...(a)gmail.com> wrote: > In practice, 'extern "C"' matters for the jump tables because for those few > compilers if any where it really matters (not just the compiler emitting a > warning like reportedly Sun CC does), different linkage can imply different > machine code level calling convention. I see. Just stick to MSVC and GNU and that never happens, just do a C style cast. > Yes, I know Boost.Python in more detail and I've heard of all the rest except > SIP, but then regarding SIP I really don't like QT You don't have to use Qt to use SIP. It's just a tool to automatically wrap C++ for Python (like Swig, except designed for C++). > And as you'd guess if you were not in silly ignoramus assertion-mode, I'm not > reinventing the wheel. It seems you are re-inventing PyCXX (or to a lesser extent Boost.Python). |