[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:243a01c20f1e$cf832870$6601a8c0 at boostconsulting.com...
> >
> > 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?
> >
>
> I realised that this functionality can be easily split into a module
totally
> separate from boost, so I'll do that and keep it for my own use where I
have
> dozens of source files in a single project that I need to create boost
> support for. It just saves creating and keeping track of a large number
of
> initialisation calls.

It's a shame that we couldn't get something into the library. However, it
was starting to look like getting something I would be willing to support
was going to be a big effort for both of us. At least the library is doing
its job: it was meant to be an extensible framework. Also, I think the idea
of dispensing with module objects altogether and using a global current
module state is a valuable one, so that's a contribution.

> > No, it doesn't have to. It just lets you hook SEH throwing at the
> innermost
> > level.
> >
>
> Initially I though this would be a problem as the handler that this
installs
> has no facility to continue in itself and if it returns it will just pass
> the excepion upwards again...
>
> However, I did some tests and found that by catching a structured
exception,
> then rethrowing a C++ exception, catching it and then rethrowing it
within a
> c++ handler will rethrow it as SE allowing it to be caught by an upper
SEH
> and then continued without error! Unfortunately I can find no
documentation
> that says this should work, but then I can find none that says it
shouldn't.
>
> I've attached my quick and dirty test project so its clear what I did.
The
> end conclusion is that we just need another catch prior to the catch(...)
> that will catch a specific seh_filter class that we define.

This is neat, but unfortunately it requires the cooperation of everything
in the call chain. If the standard library uses catch(...), as it is likely
to in, say, uninitialized_fill, without using your seh_filter trick, the
unwinding actions will still execute.

However, I think the enclosed demonstrates that my little module_tail hack
is /ALWAYS/ the right thing to do ;-)

You can also run it with an argument to see how it invokes JIT debugging
for unhandled SEHs.

-Dave

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: foo.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020608/79b1ff35/attachment.txt>