From: David Abrahams (abrahams_at_[hidden])
Date: 2000-12-07 19:54:53
----- Original Message -----
From: "Ullrich Koethe" <koethe_at_[hidden]>
> 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
> > understand. You need to know the held_instance type to do the
> > 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
> base_class_info baseInfo(base,
> &define_conversion<S, T>::downcast_ptr);
> add_base(ref(as_object(base), ref::increment_count));
> derived_class_info derivedInfo(this,
> &define_conversion<T, S>::upcast_ptr);
This seems to contradict the assertion that we need to know the
held_instance type. Actually, I don't know what I was thinking when I wrote
> and a corresponding forwarding function within class_builder. Now I can
Great! We should be able to set this up so you can write:
> 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
> > going to do this weekend. We can begin (on a branch of course) as soon
> > like.
> I've checked above proposal into branch 'shared_modules'. Tests are in
> directory libs/python/shared_modules.
Wonderful! I'll have a look... but that's the wrong directory for the tests.
They should either go in libs/python/test or libs/python/example. The
problem with mistakenly added modules is that you have to ask the
SourceForge people to clean them up :-(.
> > > Yes, but note that from_python/to_python only works if both modules
> > > 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.
> > that conversion depends on a successful dynamic_cast to the appropriate
> > instance_holder<T>*. My understanding of dynamic linking and how it
> > with the C++ runtime is pretty sketchy at best, but I think this just
> > 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.
Sure, in the current architecture. We could make to_python() and
from_python() independent but I don't think it would buy much.
> 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.
OK, I'll have a look.
> > > 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
> > module might be initialized during another module's initialization.
> Sounds right to me. Can you add that?
Sure, it would be easy. But is it needed for anything we're currently doing?
If so, should I add it to an existing branch?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk