[C++-sig] Re: Interest in luabind

Ralf W. Grosse-Kunstleve rwgk at yahoo.com
Sun Jun 22 22:51:49 CEST 2003

--- Daniel Wallin <dalwan01 at student.umu.se> wrote:
> I mostly agree with everything you say. However, it may
> still be of interest to be able to bypass the dynamic
> dispatch system and use converters with static dispatch. I
> fail to see how wrapping arrays of user-defined types is
> easier with dynamic dispatch though.

Maybe I wasn't precise enough here. It's not the wrapping that is
easier***, but that fact that I do not have to explicitly export and
import the converters.

> How do you import the converters from one module to another?

Hm, not having done the implementation I cannot tell for sure. I am
guessing that the registry, which resides in boost_python.dll, holds
essentially a few pointers to functions for the convertible() test and
the construct() stage. The machine code for these functions is in the
extension with the wrappers (i.e. the translation unit with the class_<>
instantiation). The other extensions get these function pointers from
the registry and then use the machine code from the first extension.
David, is this a reasonably accurate view?

> And how does type_info objects compare between dll
> boundries?

Again I can only offer a second-hand view. IIUC, on some platforms it is
possible to compare type_info objects across dll boundaries as if they
are in the same static link unit. I.e. there is nothing special. On some
platforms this is not possible, and type_id::name is used instead.
There is only one platform where relying on type_id::name caused a bit
of a hick-up, namely IRIX/MIPSpro. See the comment near the top of the
flew_fwd.h file (link in my previous message).

Anecdotal: when I first suggested the cross-module feature I had not
only no idea what to call it, but also no idea of all the difficulties
that we would run into. There were moments when I thought there is just
no way to get around a particular problem. The MIPSpro type_id::name
was one, but not the worst. That was issues with catching exceptions
thrown in one extension with the corresponding catch statement in
another. In retrospect it almost seems like a miracle that we got it to
work on all platforms eventually, but it does! Until quite recently I
wasn't sure about Mac OS 10 but even that we got to work now (at least
without optimization). I've also had success on an Itanium2 based
system, so there is not much out there that we have not tried.


*** Footnote: For several reasons wrapping with Boost.Python V2 is a
lot easier compared to wrapping with V1, but maybe static vs. dynamic
dispatch is not the crucial difference.

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

More information about the Cplusplus-sig mailing list