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

[David Abrahams]

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

> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:20c801c20e3f$220078e0$6601a8c0 at boostconsulting.com...
> >
> > From: "Dave Hawkes" <daveh at cadlink.com>
> >
> > (BTW, if you're doing what I think you are, the linker may be free to
> > remove the translation units containing the submodule definitions,
which
> > would break this scheme -- AFAIK, explicit calls are the only portable
> > way).
> >
>
> I've implemented this for demonstration purposes, and no the linker won't
> remove the functions as there addresses are taken by reference in a way
that
> can't be optimised out.

No static initializations need to be performed in translation units whose
functions are not otherwise called. If you're relying on static
initialization for this, please see 3.6.2 para. 3 in the standard.

> > Access violations as exceptions are outside the scope of the C++
standard.
> > I don't care what happens if there's an access violation -- some
invariant
> > is broken and the program can't recover reliably anyway. Note the
contents
> > of libs/python/test/module_tail.cpp which turns these into nice
> > JIT-debuggable crashes.
> >
>
> In which case there is no need to keep it there

By "it" you mean module_tail.cpp?
I care what happens in my tests; I want a crash to crash in a way I can
debug it.

> , but on the other hand if it
> is kept there it has no detrimental effect and may be useful if something
is
> changed in the future that may create the potential of exceptions at this
> point.

I don't know what you're talking about here.

> > > > What SEH exceptions are continuable?
> > >
> > > Usually floating point exceptions where we use the MS _fpieee_flt
> > > functionality. Typically done in CAD packages that heavily use
floating
> > > point so we can correct minor overflow/underflow/Inexact problems
> without
> > > aborting the program. Of course libraries with catch(...) handlers
are a
> > > menace in this case as it prevents the outer floating point SEH block
> > from
> > > catching the exception.
> >
> > More SEH perversity. Is there a way to get the SEH resumption to happen
at
> > a lower level?
> >
>
> Not easily I suspect, without all sorts of rather inconvenient hooks to
get
> an inner try-except to do what the user wants.

What about _set_se_translator?

> I've also implemented some code that allows functions and classes to be
> added without chaining so we can do this:
>
> BOOST_PYTHON_MODULE_INIT(PyTest)
> {
>     boost::python::def("Test1", Test1);
>
>
boost::python::add(boost::python::class_<ctest>("ctest").def_init().def("se
t
> _v", &ctest::set_v).def("get_v", &ctest::get_v));
>     boost::python::module(".sm");
>     boost::python::def("Test2", Test2);
>     boost::python::module("PyTest.sm.sm2");
>     boost::python::def("Test3", Test3);
> }

Stripping out the qualification and reformatting:

BOOST_PYTHON_MODULE_INIT(PyTest)
{
    boost::python::def("Test1", Test1);

    add(boost::python::class_<ctest>("ctest")
        .def_init()
        .def("set_v", &ctest::set_v)
        .def("get_v", &ctest::get_v));

    module(".sm");
    def("Test2", Test2);
    module("PyTest.sm.sm2");
    def("Test3", Test3);
}


Nice, but let's dispense with add(...) for classes, as long as you have a
global which denotes the current module.

> A similar rationale could probably be applied to classes as you suggested
> earlier, but I haven't tried that yet.

Actually it couldn't. There's an interaction between .def() and the class
type being wrapped.

> Now I was going to send you a diff, but the current CVS appears to be
broken
> when I include module.hpp...

I think those problems are getting resolved, if they are not already.

-Dave