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

[Dave Hawkes]

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:1efd01c20dc9$a1aa10e0$6601a8c0 at boostconsulting.com...

> > > 2.> > as it relies on its static element to be resolved in the
extension
> module.
>
> That's non-portable. Basically, you can write code that uses static
members
> as long as it's OK if they're shared between the things that are linked
> together, but does not require it. Code that requires non-sharing of
> identically-named objects may fail on some platforms.
>

I don't know of any platforms that do that as it would be difficult to
implement unless all functions were exported, though come to think of it I
seem to remember a codewarrior for mac option that exports everything, but
then I suppose all your shared libraries together become a single
translation unit. That aside I can probably fix it by making the module_link
a base class of a new class that is created using the module name which then
holds the static singleton.

> > That way multiple extension modules linked to a common boost shared
> library
> > will have different singletons to identify themselves to the common
> module
> > code. Everytime a new module is instantiated the module_link carries a
> > 'link' to the main module associated with the calling extension.
>
> There are other, better ways to handle this, that don't stress the ODR so
> much.
> You can use the unnamed namespace, for example.
>

I'm not sure how to accomplish this by using an unnamed namespace, probably
the solution I outlined above is adequate and won't rely on the ODR.

> > BOOST_PYTHON_MODULES()
> > {
> >     module(".sm").def("another_function", another_function);
> > }
> >
> > This macro would automatically chain from BOOST_PYTHON_INIT even in
> separate
> > code modules.
>
> Why do we need the macro?
>

To save the user the bother of calling the other init functions directly
inside BOOST_PYTHON_MODULE_INIT

> > This would make implementing large libraries easier as python
> > definitions could be added alongside their implementations. Note the
> > contraction above where a leading dot automatically signifies
> construction
> > of a sub-module. Also note that order of construction of modules is
> handled
> > transparantly, a sub-module can be defined before its parent.
>
> Bizarre. What makes that work?
>

As part of the process of creating a sub-module, each parent must be checked
to see if it exists at each step. If it does not exist we could either
assert or transparantly create it anyway. I just chose to do the latter.
Then if the parent is referenced later we just pull a reference to the
previously created but yet unused module.

> > > 3. What's the rationale behind the name "module_link"?
>
> Answer?
>

I thought that may be clear from the previous explanation. It provides a
link between the main module, the boost shared library and the actual
extension.

> > > 5.
> I'm not sure about it yet. Your module_link class is a very strange design
> and the bulk of the work is in init_sub_module, which as I said is too
> dense to evaluate.
>

I'll refactor the init_sub_module in the next few days and send you another
diff.

> > > 6. What is the point of module_link's p_primary_module? It never gets
>
> Once you deconvolute that design, as Ralf likes to say, I might be happier
> with it...
>

I'll look in to simplifying it as part of changing the module_link
structure.

> > > 8.
>
> PyObjects don't have destructors. Do you mean its __del__ method? It still
> won't throw a C++ exception.
>

Yes I mean __del__ method which in our case can eventually land up calling:-

delete static_cast<function*>(p);

as part of cleaning up a module.

Also note that there is a final catch(...) which catches more than just C++
exceptions when using MSVC. In MSVC it will also catch access violations and
floating point exceptions (etc.). As an aside these are best handled by SEH
anyway, particularly when they are continuable, but I'm not going to suggest
an SEH block function for continuable floating point exceptions prior to the
catch(...)...

> > > 9.
> > see MS KB Q122675. If the destructor is not virtual then the new occurs
> with
> > the heap of the extension module and the delete occurs with the context
> of
> > the boost shared library.
>
> So what? We're linked to a shared runtime.
>

That maybe, but MS still provides a separate local heap for different dlls,
just try a straight malloc in one dll, passing the pointer to another and
freeing it. new and delete just use the regular malloc and free and have the
same issues if care is not taken.

Also not that, in fact, we may not even have a common run time for a number
of reasons. Sometimes the libraries are statically linked for localisation
reasons or to get around some MFC bugs/features that can only be resolved by
statically linking.


> > I got exceptions as a result of this and adding
> > the virtual destructor fixed it.
>
> Please provide a reproducible test case.
>

If your still not sure a virtual destructor is needed I'll look at packaging
up my MSVC test workspace files and sending them to you. Alternatively I
could use one of the other techniques that don't require a virtual
destructor to fix the problem.

Dave Hawkes