Jump to content
  • Advertisement
Sign in to follow this  
gjl

Binding Native Functions for Imports

This topic is 1333 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

 

The interface of the engine makes it possible to manually bind imported functions to native functions (instead of scripted functions from a module), which is very convenient if you want to create pseudo modules using native code: you can simply call BindImportedFunction() with the native function you want to bind.

 

However, the engine currently assumes that bound functions are always script functions (so doing what I described above crashes). Is there any good reason for that?

 

The attached patch seems to fix this (that's an ugly copy/paste from function call code so it can probably be cleaner than that). Would it make sense to support this behavior?

 

 

Share this post


Link to post
Share on other sites
Advertisement

The current import function feature is something I'm planning on retiring eventually. 

 

It would be better if you used funcdefs and function handles, which support both script functions and registered functions, as well as delegates.

 

// use of the old import feature
import void func() from 'mod';  
 
// equivalent code with the more generic solution funcdefs and function handles
funcdef void FUNC();
FUNC @func;

 

The function handle can then be set from the application to point to whatever asIScriptFunction you want (as long as the signature matches :)).

Share this post


Link to post
Share on other sites


The current import function feature is something I'm planning on retiring eventually. 

woops, good to know! What is the reason for that? It sounded like a nice feature to have such a built-in linker!

 


The function handle can then be set from the application to point to whatever asIScriptFunction you want (as long as the signature matches ).

That's a nice idea, indeed! (with probably less overhead too). However, the syntax is not very nice if there are lots of functions with different types to import.

 

In fact my goal is to allow script users to dynamically load native symbols from the script before using them, with something like:

#include "ModuleAHeader" // define functions for module A
#include "ModuleBHeader" // define functions for module B

void main()
{
   // load the module (all native functions)
   LoadModule("ModuleA");

   // Use functions from module A
   FuncFromModuleA();
}
And in "ModuleA.h"

// simple function declaration, but which clearly states that it is imported
import void FuncFromModuleA() from "ModuleA";
 

This is to avoid binding all symbols at script startup (and maybe choose different implementations of the same symbols as well). Is there maybe another clean way to do this already? 

Share this post


Link to post
Share on other sites

The current implementation of imports is very limited. I'm planning on replacing it with a better solution. In the new solution it will be possible to import not only functions, but variables, classes, and entire namespaces. 

 

 

The syntax with the use of the funcdefs and function pointers may not be very nice, but this code can easily be generated by a pre-processor, so the actual syntax that the script writer writes may for example look like this:

 

#import void func() from "moduleA";

 

and the pre-processor would translate this into:

 

funcdef void func_t(); func_t @func;

 

The pre-processor would even be able to automatically set the function pointer after the compilation completes. In a similar manner to the BindImportedFunction function works today.

 

In fact, I'll probably implement this as part of the CScriptBuilder, as a way to provide some backwards compatibility once I retire the existing implementation for imported functions.

Share this post


Link to post
Share on other sites

Thanks! This also requires a change to the JIT. I'll submit a patch there too.

 

Your new system looks much better anyway. Do you know if this may happen in the near future?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!