Boost logo

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