Jump to content
  • Advertisement
Sign in to follow this  
Sir Ementaler

Test if an import succeeded.

This topic is 916 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

I was experimenting with the import functionality today, trying to implement some basic support for bound functions in our application. Our script modules, whenever they coexist, always share lifetimes, so I thought the simplest thing to do would be to automatically bind all functions once all scripts are loaded. I found the method asIScriptModule::BindAllImportedFunctions, which seemed like a useful shortcut, until I found out I can't see any way to test which imports succeeded. In particular, I hoped to create a simple bool isBound(const ? &in) function available to scripts, that would test whether an imported function is safe to use. I looked into implementation details, and it seems that an asCModule method which accomplishes it would be trivial to implement, as all it would have to do is test bindInformations[index]->boundFunctionId != -1. However, as I said, I was unable to find any such method. Does there exist one? If not, could it be added?

Edited by Sir Ementaler

Share this post


Link to post
Share on other sites
Advertisement

It's true. There is currently no interface for checking if an imported function has been successfully bound or not. If you need that information, it is easiest if you do the binding yourself, i.e. manually implement a routine that does the same thing as BindAllImportedFunctions, but keep track of the functions that couldn't be bound.

 

If you take a look at the implementation of the method BindAllImportedFunctions you'll see that it is quite simple. In fact, I have long thought about retiring it completely from the core engine, and instead put it in the helper add-ons.

 

Actually, I'm planning on redesigning the import feature completely at some time in the future. That's why I haven't put much energy into making it easy to use, not even documented it. 

Share this post


Link to post
Share on other sites

I see. Our application aims for high forward compatibility of scripts, so if it's awaiting a redesign, perhaps it's better if we currently resign of import altogether and try to use a more future-proof approach.

Share this post


Link to post
Share on other sites

You can use an approach similar to C/C++ where you manually assign function pointers. This could be made simpler for the script writer through the use of pre-processor macro. This is in fact what I had planned to do in order to keep something similar to the current import feature once I go ahead and retire it so that those who use it don't get totally left out.

Share this post


Link to post
Share on other sites

Thanks. After your previous response, I actually visited the AngelScript to-do page and noticed what improvements you had in mind. Our team was discussing whether to adapt a similar approach, but for now I'll be trying something different. It's a similar concept, but rather than import functions, I'm importing interfaces. The exporting module registers a class C that implements a shared interface B, which in turn inherits from an application-registered empty interface A. It also registers a hook that returns an instance of class C. The importing module calls an application-registered function that calls the hook in another module and returns its result as a handle to A. This result is then cast to a handle of B, which is possible because it is shared. This way the importing module can call methods of an instance in another module.

 

This approach is not as straightforward as imports, but it has its advantages. It's safer, because a module may only import a selection of functions that are meant to be imported, rather than just any function it desires. On the importing side of the code, it often ends up shorter, because a single import gives the script access to all functions of another module (the shared interface B can be placed in a separate header file that just has to be #included). The most complicated part of code ends up on the exporting side, which I think is a fair price, because I expect modules that expose a functionality, akin to libraries, to be only written by the more experienced users.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!