(To follow up on http://www.gamedev.net/topic/591814-funcdefs-to-member-functions/ and http://www.gamedev.net/topic/607706-lambda-functions/ and http://www.angelcode.com/angelscript/sdk/docs/manual/doc_adv_coroutine.html ...)

I'm wondering how to allow a script to spawn a coroutine where the function signature (of the function to call in the newly-spawned script context) is not fixed/known ahead of time (and provide those parameters).

Using the script funcdef syntax, a script can create a function handle to a function-signature that I can't anticipate ahead of time. I'd like the script to then be able to spawn a coroutine using that handle as the starting point, and provide whatever params that function needs.

Is there any precedent for doing this? Or is it best to limit the script-side spawning of coroutines to a function signature that takes no params, or predefined-ahead-of-time number/type of params?

Thank you.

My recommendation is to design it so that the co-routine can take a dictionary. This way the script can pass any information it wants to the co-routine without the need for the application to have any knowledge of whatever the script wants to pass to the co-routine.

With the newly implemented support for initialization lists in the dictionaries the syntax doesn't become too weird for the script writer either.

void MyCoRoutine(dictionary @dict)
{
   ... do some processing as a co-routine
}
 
void main()
{
   dictionary values = {{'first', 1}, {'second', 2}, {'third', 3}, {'etc', 4}};
   SpawnCoRoutine(MyCoRoutine, values);
}

That seems really elegant... I'll have to investigate (I'm not using the dictionary add_on quite yet)!

Thank you very much.

I've created a CScriptDictionary object in C++, filled it in with some elements, and called script with that param.. and was able to print out all the dictionary keys.

Is there any guidance in the documentation which would be helpful as to the type id to use for this CScriptDictionary signature?

void Set(const std::string &key, void *value, int typeId);

So far I used asTYPEID_SCRIPTOBJECT when passing an std::string& to a script string (registered with the add_on), and asTYPEID_APPOBJECT when passing a void* to an application object registered as a reference type with script. Is that correct? Would I use asTYPEID_OBJHANDLE in any situation?

Thank you very much.

No, that isn't the way it works. Except for the built-in primitive types no types have a specific type id that can be determined before hand.

The only way of getting the correct type id is by querying the engine for it. You can GetTypeIdByDecl on the asIScriptEngine for application registered types, and the same method on the asIScriptModule for script declared types.

The asTYPEID_ flags can be used as bit masks on the typeid to get limited information on the type it represents.

Regards,
Andreas

I got the below working, but it appears that if the dictionary (that's passed to the coroutine) contains some application-defined value types, modifying the value type in the dictionary in the coroutine affects the dictionary that was passed into MyCoRoutine() once SpawnCoRoutine() returns.

Before I execute "MyCoRoutine" from C++, I probably have to manually create a 2nd CScriptDictionary instance, fill it in element-by-element (creating copies of application-registered value types), and pass that instance to MyCoRoutine?

void MyCoRoutine(dictionary @dict)
{
   ... do some processing as a co-routine
}
 
void main()
{
   dictionary values = {{'first', 1}, {'second', 2}, {'third', 3}, {'etc', 4}};
   SpawnCoRoutine(MyCoRoutine, values);
}

If you absolutely do not want the co-routine to modify the original dictionary, then you'll need to do what you say, i.e. do a manual deep copy of the dictionary and all its values.

However, are you sure you need this? Perhaps you can instead take advantage of allowing the co-routine to modify the original dictionary to return values, or even allowing the caller to add extra information for the co-routine afterwards.