Who can give some examples about asIScriptAny?
Author
My question very simple:
What is the asIScriptAny and asIScriptGeneric interface mean? When and how to use them?
I cannot found any stuff about them in documents :(
Author
append a new question: :)
Im now working for a angelscript common library and a coloring edit with compiler and debuger. But some of the common functions need use the string type. Yes, I can very easely register a string factory for these common functions. But someone registered owner string factory then they how to use my common library?
Im now working for a angelscript common library and a coloring edit with compiler and debuger. But some of the common functions need use the string type. Yes, I can very easely register a string factory for these common functions. But someone registered owner string factory then they how to use my common library?
The asIScriptAny is an interface to the script 'any' type. The 'any' type is a generic container that can currently store any object handle. In the future it will be able to store all types, not just object handles.
You can see an example of how this works in the sample 'CoRoutines'.
---
The asIScriptGeneric interface can be used when you cannot register a function with a native calling convention. The function should then be a cdecl function that takes a pointer to the asIScriptGeneric interface, and the arguments passed by the script to the function are accessed through the interface.
It's mostly used when portability is a major concern for the application. If the AngelScript is compiled with the AS_MAX_PORTABILITY flag defined (see as_config.h), the only calling convention that can be used to register application functions is the asCALL_GENERIC, which uses the asIScriptGeneric interface to work.
I currently don't have a sample that shows how the asIScriptGeneric interface works, but you can look at the test case 'test_generic.cpp'.
---
As for your question about strings; Since the library can only handle 1 string type at a time your common functions and the application that uses them will have to agree upon which type to use. Perhaps you could supply different versions of your common functions that uses the common string types.
If your common functions is able to work with only std::string references for parameters and return values, then the application will be able to choose whether to register the std::string or asCScriptString (which is a wrapper for std::string). At least that way you give a little choice to the application.
Regards,
Andreas
PS. Sorry about the lack of documentation. I intend to improve that with future releases, though the improvement rate will probably be a slow.
You can see an example of how this works in the sample 'CoRoutines'.
---
The asIScriptGeneric interface can be used when you cannot register a function with a native calling convention. The function should then be a cdecl function that takes a pointer to the asIScriptGeneric interface, and the arguments passed by the script to the function are accessed through the interface.
It's mostly used when portability is a major concern for the application. If the AngelScript is compiled with the AS_MAX_PORTABILITY flag defined (see as_config.h), the only calling convention that can be used to register application functions is the asCALL_GENERIC, which uses the asIScriptGeneric interface to work.
I currently don't have a sample that shows how the asIScriptGeneric interface works, but you can look at the test case 'test_generic.cpp'.
---
As for your question about strings; Since the library can only handle 1 string type at a time your common functions and the application that uses them will have to agree upon which type to use. Perhaps you could supply different versions of your common functions that uses the common string types.
If your common functions is able to work with only std::string references for parameters and return values, then the application will be able to choose whether to register the std::string or asCScriptString (which is a wrapper for std::string). At least that way you give a little choice to the application.
Regards,
Andreas
PS. Sorry about the lack of documentation. I intend to improve that with future releases, though the improvement rate will probably be a slow.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
