[newbie] Question on embedding/extending with boost::python
Hi all -- I'm working on an app that is going to be a C++ code engine which will be heavily extended through a series of Python scripts (objects, really). My desired requirements are as follows: The environment is a C++ state machine, and each Python object should persistantly maintain its own state. I assume I can instanciate a Python object and maintain it in C++, then call it when necessary. a) Embed the Python interpreter b) Be able to pass values from the C++ state machine into the Python object for internal use c) Be able to call arbitrary Python functions from C++. I am currently doing this with an event registration handler, where scripts will handle events they want to handle, along with the function that should be called when the event is fired. d) Be able to update the C++ state machine with an interface exposed from C++ I can do a and b easily enough - the examples make that clear. Where I'm having trouble is with c and d - how do I give a Python app hooks into an existing C++ state machine? I know I can write an extension easily enough, but by my understanding, that will simply give the Python object access to a series of functions, and not the objects contained in the state machine that the interpreter is running under. I could use "pull" operations, wherein the C++ app polls the objects for changed state in a loop and updates its sate accordingly, but that seems that it wouldn't perform nearly so well as if the Python scripts were able to update the C++ state machine themselves, so I'm avoiding that route. I had a co-worker suggest that I use Python as my primary execution environment instead of C++. While this would admittedly make some things easier, how much performance would I sacrifice with this route? I'm building a 3D application, and it doesn't seem that Python would be well-suited to such an application in terms of performance. There is potential for literally tens of thousands of instances of these objects to exist in this state machine, and I certainly don't want to hinder performance by moving the primary execution into an interpreted environment rather than a compiled environment. Any words of wisdom? Or am I utterly failing to communicate clearly, as I think I am? ;) Thanks, Chris
Chris, please post your Boost.Python questions to the C++-sig:
http://www.python.org/sigs/c++-sig/
"Chris Heald"
Hi all --
I'm working on an app that is going to be a C++ code engine which will be heavily extended through a series of Python scripts (objects, really). My desired requirements are as follows:
The environment is a C++ state machine, and each Python object should persistantly maintain its own state. I assume I can instanciate a Python object and maintain it in C++, then call it when necessary.
a) Embed the Python interpreter b) Be able to pass values from the C++ state machine into the Python object for internal use c) Be able to call arbitrary Python functions from C++. I am currently doing this with an event registration handler, where scripts will handle events they want to handle, along with the function that should be called when the event is fired. d) Be able to update the C++ state machine with an interface exposed from C++
I can do a and b easily enough - the examples make that clear. Where I'm having trouble is with c and d - how do I give a Python app hooks into an existing C++ state machine? I know I can write an extension easily enough, but by my understanding, that will simply give the Python object access to a series of functions, and not the objects contained in the state machine that the interpreter is running under. I could use "pull" operations, wherein the C++ app polls the objects for changed state in a loop and updates its sate accordingly, but that seems that it wouldn't perform nearly so well as if the Python scripts were able to update the C++ state machine themselves, so I'm avoiding that route.
I had a co-worker suggest that I use Python as my primary execution environment instead of C++. While this would admittedly make some things easier, how much performance would I sacrifice with this route? I'm building a 3D application, and it doesn't seem that Python would be well-suited to such an application in terms of performance. There is potential for literally tens of thousands of instances of these objects to exist in this state machine, and I certainly don't want to hinder performance by moving the primary execution into an interpreted environment rather than a compiled environment.
Any words of wisdom? Or am I utterly failing to communicate clearly, as I think I am? ;)
Thanks,
Chris
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Cross-posted to the C++ Sig. Please post all further replies there. Chris Heald wrote:
Hi all --
I'm working on an app that is going to be a C++ code engine which will be heavily extended through a series of Python scripts (objects, really). My desired requirements are as follows: [snip] having trouble is with c and d - how do I give a Python app hooks into an existing C++ state machine? I know I can write an extension easily enough, but by my understanding, that will simply give the Python object access to a series of functions, and not the objects contained in the state machine that the interpreter is running under. I could use "pull" operations, wherein the C++ app polls the objects for changed state in a loop and updates its sate accordingly, but that seems that it wouldn't perform nearly so well as if the Python scripts were able to update the C++ state machine themselves, so I'm avoiding that route.
I'm not entirely sure what your problem is. Have you looked at libs/python/test/embedding.cpp? It shows how your embedded interpreter can get access to the internals of the running C++ program. (Specifically, its classes.) Perhaps you can use that as a starting point?
I had a co-worker suggest that I use Python as my primary execution environment instead of C++. While this would admittedly make some things easier, how much performance would I sacrifice with this route? I'm building a 3D application, and it doesn't seem that Python would be well-suited to such an application in terms of performance. There is potential for literally tens of thousands of instances of these objects to exist in this state machine, and I certainly don't want to hinder performance by moving the primary execution into an interpreted environment rather than a compiled environment.
Well, my common sense tells me that you may very well be right. But the important point is that there's really no way to tell, except for trying it out. (Profiling is the key.) And surely, writing the whole thing in Python (except for the critical sections) takes less time then writing the whole thing in C++ with just some things written in Python? Taking this road could very well lead to disappointing performance as you say. But then you'd still have gained experience from making the Python prototype, and its C++ bits can most-likely be recycled anyway. I don't really feel qualified to advise you to do one thing or the other. Embedding is sometimes the right/efficient way to do things, but such situations are becoming more and more rare. I am guessing that yours is such a situation, but you could argue that making a decision on such a guess is premature opimization (and therefore evil ;)). Perhaps others here can provide additional insights. Regards, Dirk Gerrits
participants (3)
-
Chris Heald -
David Abrahams -
Dirk Gerrits