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

David Abrahams dave at boost-consulting.com
Tue Nov 25 01:31:25 CET 2003


Jonathan Warrington <jon at shirwin.com> writes:

> Ralf W. Grosse-Kunstleve wrote:
>> That's what Boost.Python is designed for: non-intrusive
>> wrapping. Macros are
>> not used very much. Most of the work is done with templates.
>> I am afraid I still don't know what your actual question is. Did you
>> already
>> work through some simple examples? The tutorial is a very good starting point.
>> Ralf
>
> Yes I've looked at the tutorial, and all the examples use the macro
> BOOST_PYTHON_MODULE() which means the classes that will be scriptable
> will have to import the Boost.Python headers, and be compiled against
> Python.  

Absolutely not.  The wrapping code which uses the Boost.Python headers
and is "compiled against" Python only needs the *declarations* of the
classes being wrapped, not their definitions.  Of course, you'll need
to have an object file or library containing the definitions of the
functions you're wrapping somewhere.

> I want to have all my scriptable classes not need to know
> anything about any scripting languages, 

Done.

> just import my scripting
> header (which also doesn't include Boost.Python) which has generic
> looking interface functions for execution, and registering functions
> and classes as being scriptable, and a dll which contains that actual
> implementations.

Not done.  With Boost.Python you register your classes in a separate
compilation unit from the rest of your code.  You can even link your
classes into a separate dynamic library so that they're not even in
the same "link unit" with any Boost.Python code.

> For example (I know this isn't a javascript forum but it's an example)
> I also have a javascript dll implementing the same interface which for
> the "register function" function will take a name string (what it'll
> called in the script) and a function pointer (the function to be
> called.)  So there is nothing language specific in the interface but
> the dll does parameter conversions between the javascript types, and
> c++ types.
>
> I've been sidetracked with other work today, but just looking through
> the straight Python C API I think I can get functions working like I
> have them working in javascript, but I would like to be able to
> register classes as well.
>
> The vague start of the interface is below, the idea is to be able to
> create dlls that implement the interface, so that if we want to change
> scripting languages for another project all we need to do, is throw a
> different dll in there, and then write the scripts in a new
> language. All the rest of the pieces of the system that register
> scriptable pieces don't even need to know anythings changed, as they
> still call the same functions to register scriptable components.
>
> //Script function takes an arg count, an arg array, and returns a value
> typedef void (*SCRIPT_FUNCTION)( int, ScriptVal**, ScriptVal* );
> struct SW_ScriptEngine{
> 	virtual void initialize() = 0;
> 	virtual void release() = 0;
> 	virtual ScriptVal* executeScript(String script) = 0;
> 	virtual bool registerFunction(String name, SCRIPT_FUNCTION func,
> 	String moduleName) = 0;
> };

Boost.Python doesn't work that way (and thank goodness!), so if you
really are wedded to an interface like that one, I wish you good luck
in your travels.

I get the vague feeling that you're so used to working in a particular way
that you're unable to see that Boost.Python would actually serve your
needs, though I could be wrong.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com





More information about the Cplusplus-sig mailing list