This article aims to explain the way functions are registered with AngelScript, and some of the differences between C++ and AngelScript that the developer needs to be aware of in order to be successful in registering the application interface that the scripts will use. The principles learned here are used in several locations, such as RegisterGlobalFunction, RegisterObjectMethod, RegisterObjectBehaviour, etc.
The asFUNCTION takes the function name as the parameter, which works for all global functions that do not have any overloads. If you use overloads, i.e. multiple functions with the same name but with different parameters, then you need to use asFUNCTIONPR instead. This macro takes as parameter the function name, parameter list, and return type, so that the C++ compiler can resolve exactly which overloaded function to take the address of.
The same goes for asMETHOD and asMETHODPR. The difference between these and asFUNCTION/asFUNCTIONPR is that the former take the class name as well as parameter.
It is possible to register a class method to be called from the script as if it was a global function. This is commonly done when exposing a singleton to the script interface, as the singleton's methods then look like ordinary global functions. When this is done the application must have a reference to the object at the time of the registration and the application must guarantee that the object is alive until it is no longer possible for the scripts to call the method.
AngelScript accepts most common calling conventions that C++ uses, i.e. cdecl, stdcall, and thiscall. There is also a generic calling convention that can be used for example when native calling conventions are not supported on the target platform.
All functions and behaviours must be registered with the asCALL_CDECL, asCALL_STDCALL, asCALL_THISCALL, or asCALL_GENERIC flags to tell AngelScript which calling convention the application function uses. The special conventions asCALL_CDECL_OBJLAST and asCALL_CDECL_OBJFIRST can also be used wherever asCALL_THISCALL is accepted, in order to simulate a class method through a global function. The convention asCALL_THISCALL_ASGLOBAL can be used to register a class method as if it was a global function.
If the incorrect calling convention is given on the registration you'll very likely see the application crash with a stack corruption whenever the script engine calls the function. cdecl is the default calling convention for all global functions in C++ programs, so if in doubt try with asCALL_CDECL first. The calling convention only differs from cdecl if the function is explicitly declared to use a different convention, or if you've set the compiler options to default to another convention.
For class methods there is only the thiscall convention, except when the method is static, as those methods are in truth global functions in the class namespace. Normal methods, virtual methods, and methods for classes with multiple inheritance are all registered the same way, with asCALL_THISCALL.
Classes with virtual inheritance are not supported natively, and for these it will be necessary to create wrapper functions. These wrapper functions can either be implemented manually, or the template based automatic wrappers from the add-on can be used.
AngelScript supports most of the same types that C++ has, but there are differences that you'll need to know when registering functions, methods, and behaviours. Make sure you read and understand the article Datatypes in AngelScript and C++.
When registering functions that take references, you must make sure to inform the correct keyword that informs the intention of the data in the reference. For example, a parameter reference that is meant to be used as input should have the keyword 'in' defined after the & character, and an output reference should have the keyword 'out'. Reference types can be passed as both input and output references, in which case the keyword 'inout' can be used, or simply no keyword at all. Value types on the other hand cannot use 'inout' references, as AngelScript cannot guarantee that the reference will be valid during the whole execution of the function.
When registering functions that take pointers, you need to determine what the pointer represents. If the pointer is to a value type though, then it can only be registered as a reference. If the pointer is to a reference type, then it can be registered as an object handle, or as a plain reference. If you choose to use the object handle then you need to pay attention to the reference counter in the type so you don't get problems with memory leaks or crashes due to objects being destroyed too early.
Registering class methods for classes with virtual inheritance is not supported due to the high complexity involved with them. Each compiler implements the method pointers for these classes differently, and keeping the code portable would be very difficult. This is not a great loss though, as classes with virtual inheritance are relatively rare, and it is easy to write simple proxy functions where the classes to exist.
If you have a lot of classes with virtual inheritance, you should probably think about writing a template proxy function, so you don't have to manually write all the proxy functions.