class GlobalVariableHelper
{
public:
  Boxed_Value & __get_global(std::string const & name)
  {
    // require read-lock for thread-safe
    return _M_globalvars[name];
  }
 
  void __set_global(std::string const & name, Boxed_Value & value)
  {
    // require write-lock for thread-safe
    __globalvars[name] = value;
  }
 
private:
  std::map< std::string, Boxed_Value > _M_globalvars;
}
 
...
GlobalVariableHelper gvhelper;
chai.add(fun(&GlobalVariableHelper::__get_global, gvhelper), "get_global");
chai.add(fun(&GlobalVariableHelper::__set_global, gvhelper), "set_global");

and in chaiscript:

set_global("foo", 100); // foo = 100;
set_global("foo", get_global("foo") + 10); // foo += 10

Probably the best way to get a "global variable" is to not make it a literal variable. Instead register a getter and setter for the variable you want to be globally visible. These functions will be global, so it's up to you to maintain thread-safety, but it will be visible to all threads.

===

oops, someone edited my post instead of reply.

I really would have expected your example to work. It seems I'm wrong, however.

You can force the issue by telling ChaiScript exactly what type you want to work with:

class Class1
{
public:
	Class1(){}
	virtual ~Class1(){};
	void Print1(){std::cout << "Print from Class1" << std::endl;}
};
 
class Class2 : public Class1
{
public:
	Class2(){}
	virtual ~Class2(){}
	void Print2(){std::cout << "Print from Class2" << std::endl;}
};
 
Class2 * pClass2 = new Class2;
 
Class2 * getClass2(void)
{
	return pClass2;
}
 
void init()
{
	Chai.add(fun<void (Class2 *)>(&Class2::Print1), "Print1");
	Chai.add(fun(&Class2::Print2), "Print2");
	Chai.add(fun(&getClass2),"get");
}

You seem to be bubbling up the question of handling derived types, something that we have avoided up until now. We'll see what's possible.

-Jason

I've started lurking on #chaiscript on freenode for anyone who happens to want to stop by. I've also registered with freenode to officially be a group, but they say registrations take a while to process.

-Jason

Fixed and fixed.

These two problems were generic to all compilers, took me a few minutes to track down the second one, and I just removed the std::swap specialization. I'm still a little confused about that one, since it was written as a template specialization, not just as an overload.

Oh well.

Hey, I think I have indeed found another issue with ChaiScript (unless I'm missing something).

My project makes use of quite a few DLLs, and about 3 of those DLLs need to have access to ChaiScript. Previously when I was using Lua and LuaBind in a similar situation, I simply passed around a pointer to the LuaBind instance (or rather, a class containing that instance, along with some extra data).

However, when I try to do that with ChaiScript I'm getting some very nasty access violations.

The problem manifests itself in two situations:
1. When I use a global ChaiScript object (i.e. static) that is NOT function local. The reason it matters whether it's function local is that the problem seems to manifest itself when the object is created "too early". The problem manifests itself when ChaiScript is created too early, I don't know what "too early" exactly is, I just know that if I defer creation of the ChaiScript object until first use, there is no problem. I can do this by either using a pointer to the ChaiScript instance and allocating it at first use, or using a local static instance.

2. Above, I noted that if I allocate the ChaiScript instance at first use, then the problem goes away. This is true, but only if the module using the object is the one that allocated it. As soon as I give the pointer to another module to use, I get the access violation again. I am compiling all modules with the same settings, so that should not be an issue, and that worked fine when I used to use LuaBind...

I'm happy to provide more information and sample code if necessary. Right now I have no idea what's going on.

Also, I should mention, the two errors I outlined above are fairly minor. This one however is critical. If I can't work out how to fix this I don't think I'm going to be able to use ChaiScript, which would be extremely unfortunate as I've grown quite accustomed to it in my (albeit short) use of it. So, help with this matter would be greatly appreciated.

Thanks.

P.S. I don't know whether this is relevant, but if you're trying to reproduce this error, you may need to know that my DLLs are not loaded 'normally'. They are 'injected' into another application. This in itself should not cause any issues though, because I'm making sure to do it safely. (I'm avoiding any potential problems which may be caused by doing anything dangerous in DllMain, by doing NOTHING in DLLMain, and opting instead to use a named export which is called once the module is fully loaded, hence making it safe to allocate any resources I want/need.)

Thank you very much. :)

Interesting, but how would you bind C++ defined operators?

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...