[C++-sig] Re: Exposing C++ objects to Python at runtime

David Abrahams dave at boost-consulting.com
Tue Nov 25 16:44:17 CET 2003

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

>>> Now the type of function1 is "void (my_class::*)(int)" and the type of
>>> function2 is "int (my_class::*)() const". How is registerFunction
>>> going to be able to deal with those member functions (and all possible
>>> others)? 
>> It's not that hard to imagine.  registerFunction just needs to
>> generate a scripting-language-independent wrapper around the member
>> function which provides the means to invoke it and a way to get the
>> arguments initialized... something like:
> However, that implies detailed knowledge of the type of the member
> function which (AFAICS) would only be available via function template
> parameter deduction (and therefore impossible for a virtual
> function). 

Of course.  You do that part of the work on the
scripting-language-independent side of the abstraction barrier.  Just
think about how Boost.Function
+ Boost.Bind makes a whole bunch of differently-typed callable things
into the same type.

> Compile-time polymorphism would be a different matter, for
> instance every class that wants to register itself with a scripting
> engine could have a member function template like this:
> // ...
>   template<typename ScriptEngine>
>   static void register_self (ScriptEngine &engine) {
>     engine.template register_class<self_type>(); // Or some such
>     engine.register_nonstatic_memfn (function1);
>     // ...
>   }
> };
> Might be handy I guess.

I've been trying to say that you you *can*, in principle, still do
this with a single ScriptEngine type, so that registration code gets
compiled once, scripting-language-independently.

I've also been trying to say that requiring coupling of the scripting
engine registration into the classes being scripted is a mistake.

Dave Abrahams
Boost Consulting

More information about the Cplusplus-sig mailing list