[C++-sig] Re: boost:python:embedding

[David Abrahams]

Dirk Gerrits <dirk at gerrits.homeip.net> writes:

> Seriously though, I have some more questions.
>
> When you are embedding Python in a C++ program, your Python code may
> need to call C++ code in the embedding program. (At least, that's
> what I currently need to do.)

That seems pretty standard.  There's probably not much point in
embedding otherwise.

> To do this, you can't simply create a module_name.so or
> module_name.pyd as you'd do when extending; the BPL wrapper code
> must be in the C++ program itself. 

Loading of plugin extension libraries is disabled? Are you sure?
I can understand why you'd want to link statically, but it seems to
me that dynamic linking should still be possible... no?

> To make the module available to Python, you must call a function
> like PyImport_AppendInittab (or interpreter::add_module which I just
> whipped up ;)). The parameters to this call are the module name and
> the init function. Herein lies the problem. If the module is in a
> different compilation unit than the code using the interpreter one
> must forward declare the init function. 

OK...

> Is there currently a way to
> do this safely? Perhaps a macro like the following?
>
> #if (defined(_WIN32) || defined(__CYGWIN__)) &&
>  !defined(BOOST_PYTHON_STATIC_MODULE)
>
> #  define BOOST_PYTHON_FORWARD_DECLARE_MODULE_INIT(name)     \
> extern "C" __declspec(dllexport) void init##name();
>
> #else
>
> #  define BOOST_PYTHON_FORWARD_DECLARE_MODULE_INIT(name)     \
> extern "C" void init##name()
>
> #endif
>
> I have some issues with this though. For starters, the macro name is
> much too long for my taste. ;) 

You could leave out the word "DECLARE".

> Furthermore, I doubt if it makes sense to do this sort of embedding
> without defining BOOST_PYTHON_STATIC_MODULE. Which brings me to my
> last question.
>
> There used to be a bug which caused a 'Fatal Python error' upon
> Py_Finalize when doing this kind of embedding. But when I ran into
> that, there was no BOOST_PYTHON_STATIC_MODULE. Now, with
> BOOST_PYTHON_STATIC_MODULE I haven't been able to replicate it. Has it
> been fixed then?

No, it hasn't.  This should still be addressed, and in fact it isn't
that difficult.  As I've said before, I'm sure you could do it with a
little hand-holding.  The problem is that some references to Python
objects are being kept alive by global data
(e.g. boost::python::object instances) which must be released before
Py_Finalize is called.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com