The short answer is that C++ operators are just functions. So, one option is to register them as such:

chai.add(fun(&MyClass::operator<), "<");

The above gets a bit tricky if your operator is a free function instead of a member, making it become something like:

chai.add(fun<bool (const MyClass &, const MyClass &)>(&operator<), "<");

A third option, which is not yet recommended, is to use the internal helpers that we have:

chai.add(fun(&bootstrap::detail::less_than<const MyClass&, const MyClass&>), "<");

The helper works for class methods or free functions, but it is in the "detail" namespace, which is not part of the public API.

A better option would be if we were to add helpers for all canonical forms of the operators. This would not be terribly difficult, and I will make a note to work on it for the next release. I'm envisioning something like:

chai.add(less_than<MyClass&>());

It was a late add, but we should probably take some time to document it. The unit tests that covers it look like:

Use operator as a method:

def Bob::`+`(y) { this.x + y.x }
def Bob::Bob() { }
attr Bob::x
var b = Bob()
var c = Bob()
b.x = 4
c.x = 5
print(b+c)

And... operator as a function

def Bob::Bob() { }
attr Bob::x
def `-`(a, b) : is_type(a, "Bob") && is_type(b, "Bob") { a.x - b.x }
var b = Bob()
var c = Bob()
b.x = 4
c.x = 5
print(b-c)

"You can register a function that takes a Boxed_Value," right, but I can't change the interface ;) I'm saying that since both Boxed_Value and boost::any can hold 'any' value, it would be useful to have a direct Boxed_Value -> boost::any conversion. This isn't a major show stopper, just thought I'd point it out.

Correct, my point is that there is no direct Boxed_Value -> boost::any conversion, you need to know the held type. Meaning I can't bind a function like this:

void doCommand(const string &name, const boost::any &value) { ... }

Cool, thanks. Some other issues I've noticed:

1) there doesn't seem to be any way to tell if a variable is "unknown" or correctly set. This is easily fixed by binding your own "is_unknown" function that returns Boxed_Value::is_unkown(), but it would be nice if this feature was built in like "to_string" is

2) similar to the above, there doesn't seem to be any way of checking for a "null" pointer. For example:

boost::shared_ptr<someClass> foo; // null pointer
chai.add(var(foo), "foo");

foo.doStuff() // woops, it's null - but how can we check?

3) at first I thought that Boxed_Value::get() would return a boost::any with the value of the object, but after looking through the code it seems to return the boost::any that has a reference or a shared_ptr to the value. I understand why this is done, but it would be useful if there was a value-based boost::any. For example:

void doCommand(const string &cmd, const boost::any &param0, const boost::any &param1) // or a vector of any's
{
   // do stuff with cmd and the proper parameters, assuming they hold value types, not shared_ptrs
}

If there was a way to get the value-based boost::any out of a Boxed_Value, the above would be very easy... but there isn't, because the any holds a reference or shared_ptr.

Something like this would work:

template<typename T>
T custom_cast(const boost::any &a)
{
    try
    {
        // try value type first
        return boost::any_cast<T>(a);
    }
    catch (...)
    {
    }
 
    try
    {
        // try pointer type second
        return boost::any_cast<boost::shared_ptr<T> >(a);
    }
    catch (...)
    {
    }
 
    throw bad_cast();
}

But then we have the issue of const-correctness, etc. Perhaps there is an easier, more integrated way of doing this...

ChaiScript, unlike most scripting languages, seems to implicit *copy*, not share, all values. This is a major problem because you end up with the following problem:

// share a value with C++ and Chai, nice!
var someValue = someSharedPtrFromCPP()
 
// make another reference to this value
var theSameValue = someValue
// WOOPS, error! the shared_ptr isn't copied, but the value is copied instead
// and if you don't have a copy constructor for that value type, then you're screwed

The above problem becomes much more important when you do something like this:

def doStuff(obj)
{
    obj.val = 42
}
 
var obj = someSharedPtrFromCPP()
 
doStuff(obj) // oh no!

I propose the following:

var obj = foo()
var sharedObj = obj // shared, no copy constructor is needed
 
var copyObj = foo(obj) // explicit copy, *not* shared with the original obj

Edit:

Actually, this seems to be a non-issue. Function parameters seem to be implicitly shared, and there exists a completely obscure operator called ":=" which does sharing instead of copying. The documentation doesn't seem to mention this operator at all, I had to look through the source to find it.

This should be available in the next release. If you would like to get it earlier and don't mind using code fresh out of subversion, the most recent revisions should allow for hex and octal.

one can't start script with {
it will cause parse error

also if (1) is invalid (that might not be an issue if one is required ot do if (true) or something.

it seems like ChaiScript (2.0) cant recognize/parse hex numbers. is that the case or am i looking at some other issue ?
(hex numbers as 0x10 etc...)

The problem here is that your ChaiScript engine is going out of scope and being destroyed before you get the chance to call begin() because you created your ChaiScript engine inside of your constructor.

The main solution would be to extend the lifetime of your ChaiScript engine, to make sure it's available when you need it.

class Test
{
public:
	Test(){
		chai.eval_file("test.chai");
		func = chai.functor<void ()>("func");
	}
	void begin(){
		func();
	}
private:
        ChaiScript chai;
	boost::function<void ()> func;
};

If this does not solve your problem, please copy the contents of your test.chai file here so we can double check what it is doing.

like

enum DIRECTOR
{
	East,
	South ,
	West,
	North 
}

how to realize?