|
Boost : |
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
> stuff.
>
Exactly. But meanwhile I realized, that it can be done simpler still.
I've added the following to extension_class:
template <class S>
void declare_base(type<S>)
{
extension_class_base * base = class_registry<S>::class_object();
if(base == 0)
throw std::runtime_error("declare_base(type<S>): base
undefined.");
base_class_info baseInfo(base,
&define_conversion<S, T>::downcast_ptr);
class_registry<T>::register_base_class(baseInfo);
add_base(ref(as_object(base), ref::increment_count));
derived_class_info derivedInfo(this,
&define_conversion<T, S>::upcast_ptr);
class_registry<S>::register_derived_class(derivedInfo);
}
and a corresponding forwarding function within class_builder. Now I can
write:
reswindow_class.declare_base(boost::python::type<Window>());
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
> like.
>
I've checked above proposal into branch 'shared_modules'. Tests are in
directory libs/python/shared_modules.
> > 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?
Ulli
-- ________________________________________________________________ | | | 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