I can't see the benefits or advantage of it, what calling c++ functions in this way?

The advantage is essentially that some part of your code does not need to be compiled. The eval function is as similar as possible to its equivalent in interpreted languages, with the main difference being that you have to briefly mention the name of functions you want to use from within the script (in an eval header). For example, one use case may be a template library (i.e. textual templates). So, you might wish to have a generic html template, which refers to a Person's first name, last name, age and so on. In your compiled code, you might have a Person class to store this information. Normally, you'd have to pass in all the details individually (or in some special aggregated class/struct depending on the template library used) as far as I know. With the foundations provided by this library, you can pass in a Person instance; the actual Person class would remain completly unmodified as well. Now, you could easily change the templates without recompilation. Furthermore, if your eval header includes most of the functions in your Person class, the compiled code doesn't have to worry about what it passes to the template (i.e. the template can pull the age, or the name, as needed). Christian

I don't see the point of creating yet another scripting language. If it were real C++, it would be cool, but it doesn't seem to be.

The point is not to create a scripting language. The point is that an eval script can take an existing instance from a C++ program and modify that (as well as create instances of existing classes and pass those back to the compiled program). So, part of a compiled C++ program could be transferred into a script (and then changed without recompiling the program); however, trying to write an entire program inside a script would be an abuse of the library. So, to clarify, when you write a << b; the library will call the appropriate operator<< method or function and that's it; there's no notion of interpreting the meaning of the code, beyond figuring out which function/method needs to be called. The flow of control would then pass to the actual compiled function, just as if you had written the function call in your program and compiled it. So, it's very much strictly a C++ thing. Now, the actual syntax of the scripts is not yet finalized. I guess one could consider it slightly more relaxed than real C++ because all variables are of a gerneric type, rather than specific type. I'm very much interested in feedback on this issue. An example script and eval header is available at http://eval.sourceforge.net Christian

Christian Hoermann wrote:

...

I don't see the point of creating yet another scripting language. If it were real C++, it would be cool, but it doesn't seem to be.

The point is not to create a scripting language. The point is that an eval script can take an existing instance from a C++ program and modify that (as well as create instances of existing classes and pass those back to the compiled program).

Most of the embedded script languages can interact with the host code in that way (mostly with C but with a bit of twiddling it works with c++ as well). To name the few: Lua (easy C integration), MS script host (COM), python (python/c & boost)... As I see it the main advantage would be c++ like syntax and almost 1:1 mapping of the constructs. There may be some use for it if was lightweight and easily integrated, but it is in fact a new script language, and when you need scripting most of the time you want a real and familiar scripting language. -- Hrvoje

Have you tried boost.python ? Also, you may want to read http://www.boostpro.com/writing/bpl.html, as that seems exactly to be what you are aiming at.

No, I hadn't looked at this previously. But, you're right, the embedding functionality of Boost.Python seems to provide the functionality of eval in Python syntax.

As I see it the main advantage would be c++ like syntax

Seems like this the common request, so I'll think about changing the syntax (the parser is only a small part part of the library). Currently the library is dynamically typed, seemingly like Boost.Python. So, each time you call a script, different methods/functions might execute, depending on the arguments. It should be possible to use C++ like syntax instead; however, this would of course mean that the code would be statically typed. Also, whilst it might be possible to get mostly C++ like syntax, there would always be limitations. For example, the library could never instantiate "new" templates; e.g if you want a vector<int>, you'd have to register it, unless a polymorphic system like Java Generics were used instead (which can likely only work for simple C++ template classes).

There may be some use for it if was lightweight and easily integrated

Well, it's currently header only and non-intrusive; so relatively easy to incorporate. However, it's probably not that lightweight in terms of compile time, run time and executable size.

Could this eval be used, somehow, to help solve the problem mentioned

I don't think so, sorry. Boost.Spirit really needs to instantiate many "new" templates, afaik. I don't think it's possible to instantiate these templates from within the script (since it actually requires compiled code generation), unless you mention them all beforehand in the compiled program, which is probably impossible in this case. Christian