Cpp + Python: static data dynamic initialization in *nix shared lib?

[Alf P. Steinbach /Usenet]

* geremy condra, on 09.07.2010 23:43:
> On Fri, Jul 9, 2010 at 5:22 PM, Ian Collins<ian-news at 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>