Our system has a function looks like this:

MyObject* getAnotherObject(std::function<int(int)> get_strategy);

This function need to be called from script side, but we prefer to allow get_strategy being implemented from script side. I immediately got some problems:

1, Is it ever possible to call a script function on the half way of native callback? Does AngelScript allow to do that?

2, How to obtain the running AngelScript context from the function wrapper side? I only find GetEngine() in asIScriptGeneric that give you corresponding engine, but don't know how to get context.

3, The C++ function probably should be registered as MyObject@+ getAnotherObject( CallbackFunc@ ), where the callback function probably looks like funcdef int CallbackFunc( int );. However, at the time C++ function is registered, the funcdef to callback function does not exist, as source code is compiled after C++ type registration. How should I solve this?

1) Yes, it is possible. You can reuse the current script context by first pushing the call state so a new call can be setup, or you can use a separate script context obtained from the engine.

2) You can get the current running context with a call to the global function asGetActiveContext.

3) If the funcdef doesn't rely on any script declared types you can just register it from the application directly with RegisterFuncdef. If the funcdef relies on script declared types then you can use something like the generic ref type instead and then have the C++ determine the type at runtime.

@WitchLord If I can ensure there is only one context for each engine, can I get the context from engine→RequestContext()?

What is the behavior of the context pooling implemented in CScriptEngine?

And do I need to fill the context callbacks, or just leave them blank?

Yes, if you can ensure that, then you could use the context pooling callback to return that context instance when you call RequestContext. You could also simply store the address of the context instance in the engine's user data.

There is no built-in context pooling. New contexts are allocated each time one is requested. To use context pooling you need to register the context pooling callback.