You are running into an issue that I've been debating how to address. The problem is that functions are preferred in the order they are declared, so the built in chaiscript functions are being called and the function call itself is a match, even tho something further down in it fails.

My proposed solution is to not blindly call functions in the order they are declared, but instead to sort them as they are added to the engine such as:

1. Typed C++ Functions
2. Typed C++ Functions with const parameters (ie, const members)
3. Guarded chaiscript functions
4. Unguarded chaiscript functions

This way, the most specific function will be tried first, leading to the least specific functions.

There's been some disagreement amongst the developers as to the order of the function calls, that the above is what makes the most sense to me. Using the above, the user (such as yourself) can provide your own specific implementation of any existing function name.

-Jason

I've been pondering more advanced conversions, like you pointed out. Ones that would feel natural to a C++ developer, but would not necessarily be built into the language. I'm not convinced of the best way to do it yet, or if it's even a good idea.

As a compromise, I've exposed the .data() and .c_str() methods to the string class.

Before I give an example, I'd like to point out two potential issues with your above code. First, c_str() is the recommended method, not data() because c_str() is guaranteed to be null terminated, the other is not.

Second, in your example, you have a pretty bad memory error. You are creating a string object and returning a pointer to its internal data. As soon as "return" executes your string (msgcontent) is popped from the stack and the pointer you are returning is no longer valid.

Now for how you might use the new methods:

getField(2, "notice".c_str());

There's been several posts that make reference to static chaiscript objects and your example is setting to a static chaiscript::function. I just want to point out that I have a hard time recommending using chaiscript and related objects as statics. I would say there's a good chance that you will at some point run into problems during object destruction on some platform (during application shutdown).

That said: your functor<> issue is fixed in SVN, and I added a unit test to make sure I don't re-break it. Fundamentally, the problem is that you had a const function variable "func," and the functor<> call was expecting a non-const value. It was simply a bug.

You can either check out SVN, or you can make a temporary variable that should work the same:

def func() { print("Hello World"); }
var func2 = func;

boost::function<void()> f = chai.functor<void ()>("func2");

-Jason

Supporting VS2003 is not high on my list, however, it *should* work, since vs2003 is supported by boost, and we rely heavily on boost.

If you would make a bug report on chaiscript.googlecode.com, I'll do my best to look into it when I next go to work on vs2010 support - to make sure I reduce any new warnings found there.

-Jason

There are a variety of techniques that can be used to share data between chaiscript defined objects and C++. I've just checked in a unit test to verify that it all worked, and provide some examples.

Regarding forcing a variable to be a certain type or not, let's start by clarifying terminology. Hopefully I have this right, but ChaiScript is a strongly typed dynamic language. The variable type is determined at runtime, but once it is set, it is set permanently. There are very few automatic type conversions. Conversions between pointer, reference, const, boost::shared_ptr happen automatically, whenever they safely can. Pointers that would require modifying the underlying type (ie, int->float) do not happen automatically.

There is exactly one type of variable declaration in ChaiScript, the "var" that has its type set on the first assignment operation.

However, you can force something to be a certain type during a function call by using function guards, like:

fun test(x) : x.is_type(int_type) {
 
/* do something */
 
}

Hope that helps.

-Jason

No, this is not possible. In ChaiScript, technically, methods do not exist; only functions exist.

So, a method call like:

obj.somefunc();

Is translated to:

somefunc(obj);

So, fundamentally, the user will always be allowed to add functions that can operate on your class. This means that the method sugaring we perform essentially means that all classes are always extendable, inside of script.

Unless I miss your meaning. What affect are you going for? What is your use case?

Im thinking that both my errors are caused by the same thing.
(like some portion of the stack is not being initialize)

I'm getting exactly the same issue.

I'm using boost 1_37_0 with mthreading

Adding any var from c++ causes a crash in add_object, can't solve it so far

To my memory, there aren't yet ways to do number literals like you describe, though it shouldn't be too difficult to support them.

In ChaiScript, we intentionally focused on flexibility over performance. Why? Let's think about how you might use a scripting language in a C++ application:

You build up your C++ app, but realize parts should be runtime configurable. These types of things might be settings, business logic, or game scripts.

These call back into the engine to fire off the events or set the values for you. The script itself is merely a set of calls back to the main application.

In ChaiScript, we went one step further. The entire script is calls back to the ChaiScript engine and your application. Every addition, every step of the loop, is all calling back to ChaiScript. This makes it generally less performant, but in return you get the ability to augment what each script does to the nth degree.

We chose to put less restrictions on the programmer. We could have tightened things down and prevented that level of modification, and for our efforts we might have gotten something of a speed increase, but in our opinion, if you're using ChaiScript for time critical things, you're using it wrong. Put the time critical sections in C++ where they will always work best, and fire them off from your script.

Hope that helps.

It would appear that you have a typo in your main.chai:

var x = LoadAnimMesh("C:\man.b3d")

should be:

var x = LoadAnimMesh("C:\\man.b3d")

Normal C++ escaping rules apply.

We should post your example for others to look at. Using the template to help you register the signal functions is what we needed to do when exposing std container classes.

Unfortunately there is not (and cannot be) a more generic way of exposing templates because we need to know the function pointer address of the functions we want to call at compile time. The only way to know these addresses is to instantiate the templates that are being used, and get the functions from them, as you did.

The important thing to realize, as you did, is that a template member is just like any other function, you just have to be explicit about which instantiation of the template you are referring to.

-Jason

In ChaiScript there aren't global variables. You can register a constant value in your C++ application that is global, but you can't make a variable that all functions can see.

If you're curious why:

The short answer is that global variables aren't good practice.

The long answer is that we liked the idea of reusable functions in ChaiScript. The easiest way to make reusable functions is to always have a function's parameters be explicit, so you can just call it from any context and know you're passing in everything it needs.

The even longer answer is that ChaiScript is automatically thread-safe. If you take the same engine and call scripts in different threads, this should, in theory, "just work". Having global variables makes this automatic safety difficult and the implementation hairy (since now some variables would be handled differently than others).

I'll look into it this evening, not sure why you would have a problem with that one.