* geremy condra, on 09.07.2010 23:43:
On Fri, Jul 9, 2010 at 5:22 PM, Ian Collins<ian-n...@hotmail.com> wrote:
On 07/10/10 03:52 AM, Alf P. Steinbach /Usenet wrote:
[Cross-posted comp.lang.python and comp.lang.c++]
I lack experience with shared libraries in *nix and so I need to ask...
This is about "cppy", some support for writing Python extensions in C++
that I just started on (some days ago almost known as "pynis" (not funny
after all)).
For an extension module it seems that Python requires each routine to be
defined as 'extern "C"'. And although e.g. MSVC is happy to mix 'extern
"C"' and C++ linkage, using a routine declared as 'static' in a class as
a C callback, formally they're two different kinds, and I seem to recall
that /some/ C++ compiler balks at that kind of mixing unless specially
instructed to allow it. Perhaps it was the Sun compiler?
Yes, it will (correctly) issue a warning.
As the is a bit OT, contact me directly and we can work through it. I have
had similar fun and games adding PHP modules!
I'd appreciate it if you'd either leave this on-list or cc me in on this, as
I'm working through a similar issue.
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).
I believe Boost's Python binding uses (A), or perhaps (B).
Cheers,
- Alf
PS: You (the reader) may be wondering, why why why Yet Another Python/C++
binding? Well, because I had this great name for it, "pyni", unfortunately
already in use. But cppy is very different from Boost: Boost is large, cppy is
tiny; Boost has as main goal to expose arbitrary C++ code to Python, automating
argument conversion etc., while with cppy your Python design is exposed to C++
with no enforced arg conversions and such; Boost relies on canned magic,
difficult to subvert when it doesn't do what you want, while with cppy you are
(or, so far, I am) in control; and I suspect that the Boost Python binding,
relying on dynamic registries and stuff, is not all that efficient, while cppy
is as efficient as using the Python C API to create an extension. And besides,
cppy supports national characters in doc strings etc. And I'm Norwegian. So. :-)
--
blog at <url: http://alfps.wordpress.com>
--
http://mail.python.org/mailman/listinfo/python-list
