alanbaljeu at yahoo.com
Wed Nov 12 16:40:56 CET 2008
>It seems your question is all about the boundary / interface between the (C++) application and the script that gets invoked: What should the content of the dictionary be, and what is the script expected to do with it ?
>In the most trivial case such a script could simply store named values (numbers, strings) into the dictionary, which then get evaluated
>by the application. The script thus becomes a mere configuration file.
>Alternatively, you can inject functions or even objects into the dictionary, which the script is expected to interact with. How much 'Object-Orientedness' makes sense really depends on your needs, which you haven't >talked about yet.
Okay I'll try. I'm growing a CAD plug-in DLL. I have decided that the edit/compile/run/test cycle is too slow both because C++ is a bear, and because both compile and run steps are extremely slow in my environment.
To solve this, I intend to write as much Python as possible, to drive C++ objects, so I won't have to recompile, or restart my environment. (Previous use of python had a slightly different goal: use Python minimally for a dynamic modeling problem) So Python code will consist of interactive and non-interactive scripts. These scripts receive objects, work with them, and return other objects. There are no persistent Python objects. There are probably Python classes designed as temporary wrappers of C++ classes.
1) Embed Python in this C++ plug-in. [Done.]
2) Expose C++ objects (functions and/or data) defined by the plugin to Python.
3) Write code in Python to create and manipulate those objects. (exec, not eval)
4) Write code in C++, but only when required to make (2) easy. (Abundant existing code may hinder my goals, and force more C++)
5) Develop a library of unittest methods.
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at
More information about the Cplusplus-sig