[C++-sig] Re: Re: sub module support in V2

[David Abrahams]

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>


> Here's the new sub-module code
>
> I've put in the support that allows:
>
> BOOST_PYTHON_MODULES(a1)
> {
>     boost::python::module("PyTest.sm.sm2");
>     boost::python::def("Test3", Test3);
> }
>
> where a1 is a name unique to each BOOST_PYTHON_MODULES declaration.
>
> Yes, the support does rely in part on static initialisations but as these
> are in the same translation unit as the python init##name then they must
be
> constructed. If init##name is not called, then it doesn't matter if they
are
> not constructed anyway. The one thing I have avoided is using any memory
> allocation functions in global static initialisers as I've run into
problems
> when that occurs on occasions.

Sorry to be nitpicky, but I don't like that interface. Any interface which
introduces new macro cruft /and/ requires that the cruft be in the same TU
with BOOST_PYTHON_MODULE_INIT() seems like it provides too few advantages
to offset its drawbacks. Why not just have the main init function call the
other init functions?

> > What about _set_se_translator?
> >
>
> Doesn't help, it turns SEH exceptions into c++ exceptions

No, it doesn't have to. It just lets you hook SEH throwing at the innermost
level.

> at which point
> they become non-continuable which is what we are trying to avoid in the
> first place. Also I believe the SEH frame is corrupt after the c++ catch
so
> it would be difficult to rethrow an SEH exception at that point that
could
> be continued from it point of origin.

What catch? I'm just talking about installing some kind of handler with
_set_se_translator so that these continuable things are dealt with instead
of turning them into unwinding.

-Dave