From: Ullrich Koethe (koethe_at_[hidden])
Date: 2000-12-07 19:18:52
David Abrahams wrote:
> > Note that we
> > can't use extension_class directly because we don't know the
> > held_instance type if callbacks are enabled.
> It took me a little while to figure out what you were saying, but now I think I
> understand. You need to know the held_instance type to do the downcast/upcast
Exactly. But meanwhile I realized, that it can be done simpler still.
I've added the following to extension_class:
template <class S>
extension_class_base * base = class_registry<S>::class_object();
if(base == 0)
throw std::runtime_error("declare_base(type<S>): base
and a corresponding forwarding function within class_builder. Now I can
If one also needs from_python/to_python() for Window, one has to
instantiate python_extension_class_converters<Windows> by the usual
means. It is probably good to do this in a header which is included by
all modules that want to share this class.
> OK, we should definitely explore this for the release following the one Beman is
> going to do this weekend. We can begin (on a branch of course) as soon as you
I've checked above proposal into branch 'shared_modules'. Tests are in
> > Yes, but note that from_python/to_python only works if both modules use
> > the same extension_class instances - otherwise, Python would report
> > incompatible classes even when the wrapped C++ classes were identical.
> That's definitely true of to_python. I'm not so sure about from_python. Really,
> that conversion depends on a successful dynamic_cast to the appropriate
> instance_holder<T>*. My understanding of dynamic linking and how it interacts
> with the C++ runtime is pretty sketchy at best, but I think this just means the
> modules need to be dynamically linked with one another.
But from_python() must still be defined by instantiating
python_extension_class_converters, which requires knowledge of the
instance holder. This should be done in one place (e.g. in a header file
shared by all modules.)
> Common source files? Common headers? Common objects? I'm a bit lost.
See above and libs/python/shared_modules/shared.hpp for an example.
> > But
> > after dynamic linking of "logicmodule.so" against "uimodule.so", there
> > are two module_builders in "logicmodule.so". This is not an error,
> > because uimodule's module_builder is not used in "logicmodule.so".
> Probably the best solution would chain the name_holders into a stack, in case a
> module might be initialized during another module's initialization.
Sounds right to me. Can you add that?
-- ________________________________________________________________ | | | Ullrich Koethe Universität Hamburg / University of Hamburg | | FB Informatik / Dept. of Computer Science | | AB Kognitive Systeme / Cognitive Systems Group | | | | Phone: +49 (0)40 42883-2573 Vogt-Koelln-Str. 30 | | Fax: +49 (0)40 42883-2572 D - 22527 Hamburg | | Email: u.koethe_at_[hidden] Germany | | koethe_at_[hidden] | | WWW: http://kogs-www.informatik.uni-hamburg.de/~koethe/ | |________________________________________________________________|
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk