Registering a value type

When registering a value type, the size of the type must be given so that AngelScript knows how much space is needed for it. If the type doesn't require any special treatment, i.e. doesn't contain any pointers or other resource references that must be maintained, then the type can be registered with the flag asOBJ_POD. In this case AngelScript doesn't require the default constructor, assignment behaviour, or destructor as it will be able to automatically handle these cases the same way it handles built-in primitives.

If you plan on passing or returning the type by value to registered functions that uses native calling convention, you also need to inform how the type is implemented in the application, but if you only plan on using generic calling conventions, or don't pass these types by value then you don't need to worry about that.

// Register a primitive type, that doesn't need any special management of the content
r = engine->RegisterObjectType("pod", sizeof(pod), asOBJ_VALUE | asOBJ_POD); assert( r >= 0 );
 
// Register a class that must be properly initialized and uninitialized
r = engine->RegisterObjectType("val", sizeof(val), asOBJ_VALUE); assert( r >= 0 );

See also

The string object or the complex type in the math add-on for examples of value types

Registering a generic handle type for a more specific example of a value type

Garbage collected objects for when the type may form circular references when being a member of another type

Constructor and destructor

If a constructor or destructor is needed they shall be registered the following way:

void Constructor(void *memory)
{
  // Initialize the pre-allocated memory by calling the
  // object constructor with the placement-new operator
  new(memory) Object();
}
 
void Destructor(void *memory)
{
  // Uninitialize the memory by calling the object destructor
  ((Object*)memory)->~Object();
}
 
// Register the behaviours
r = engine->RegisterObjectBehaviour("val", asBEHAVE_CONSTRUCT, "void f()", asFUNCTION(Constructor), asCALL_CDECL_OBJLAST); assert( r >= 0 );
r = engine->RegisterObjectBehaviour("val", asBEHAVE_DESTRUCT, "void f()", asFUNCTION(Destructor), asCALL_CDECL_OBJLAST); assert( r >= 0 );

Remember to use unique names or namespaces for the wrapper functions, even if you create templated implementations. Otherwise the linker may end up taking the address of the wrong function when registering the wrapper with AngelScript, which is sure to result in unexpected behaviours.

Note that you may need to include the <new> header to declare the placement new operator that is used to initialize a preallocated memory block.

List constructor

The list constructor is similar to the list factory function for reference types. The constructor will receive a pointer to the initialization list buffer in the exact same way, and the expected list pattern should be registered in the same way. The difference is that the list constructor should be registered like a method, just as done for other constructors.

Example registration of a list constructor:

engine->RegisterObjectBehaviour("vector3", asBEHAVE_LIST_CONSTRUCT, "void f(int &in) {float, float, float}", ...);

See also

The complex math add-on for an example value type with a list constructor.

Value types and native calling conventions

If the type will be passed to or from the application by value using native calling conventions it is important to inform AngelScript of its real type in C++, otherwise AngelScript won't be able to determine exactly how C++ is treating the type in a parameter or return value.

If the flags that inform about the actual type are not informed and AngelScript needs them on the platform, you'll get an error message like "Don't support passing/returning type 'MyType' by value to application in native calling convention on this platform".

To inform AngelScript of the actual type in C++ the template function asGetTypeTraits should preferably be used as it will automatically determine most of the flags to pass to RegisterObjectType together with the asOBJ_VALUE flag.

// With C++11 the type can be registered with GetTypeTraits
r = engine->RegisterObjectType("complex", sizeof(complex), asOBJ_VALUE | asGetTypeTraits<complex>()); assert( r >= 0 );

The following flags are covered by asGetTypeTraits:

asOBJ_APP_CLASS	The C++ type is a class, struct, or union
asOBJ_APP_CLASS_CONSTRUCTOR	The C++ type has a default constructor
asOBJ_APP_CLASS_DESTRUCTOR	The C++ type has a destructor
asOBJ_APP_CLASS_ASSIGNMENT	The C++ type has a copy assignment operator
asOBJ_APP_CLASS_COPY_CONSTRUCTOR	The C++ type has a copy constructor
asOBJ_APP_PRIMITIVE	The C++ type is a C++ primitive, but not a float or double
asOBJ_APP_FLOAT	The C++ type is a float or double
asOBJ_APP_ARRAY	The C++ type is an array

On some platforms the native calling convention may require further knowledge about the class and its members that asGetTypeTraits cannot determine in order to work properly. Whether or not the flags are needed depends on the compiler and target platform, but if the flags are not needed AngelScript will simply ignore them so there is no harm in informing them.

Be careful to inform the correct flags, because if the wrong flags are used you may get unexpected behaviour when calling registered functions that passes or returns these types by value. Common problems are stack corruptions or invalid memory accesses. In some cases you may face more silent errors that may be difficult to detect, e.g. the function is not returning the expected values.

AngelScript lets the application give information that cover the most common variants, e.g. the class should be treated as if all members are integers (or non-float primitives), or it should be treated as if all members are floats. It is also possible to inform if the class has more constructors than the traditional default and copy constructors. This last one normally only has importance if the default and copy constructors are defaulted.

asOBJ_APP_CLASS_MORE_CONSTRUCTORS	The C++ class has additional constructors beyond the default and copy constructors
asOBJ_APP_CLASS_ALLINTS	The C++ class members can be treated as if all integers
asOBJ_APP_CLASS_ALLFLOATS	The C++ class members can be treated as if all floats or doubles
asOBJ_APP_CLASS_ALIGN8	The C++ class contains members that may require 8byte alignment, e.g. a double.
asOBJ_APP_CLASS_UNION	The C++ class contains unions as members.

Here's some examples to better illustrate the use of the flags:

// The presence of the constructor with parameters indicates that the flag asOBJ_APP_CLASS_MORE_CONSTRUCTORS should be used
struct A
{
        A() = default;
        A(const A& o) = default;
        A(float x, float y) { this->x = x; this->y = y; }
};
 
// The structure only contains non-float primitives so asOBJ_APP_CLASS_ALLINTS should be used
struct B
{
        int a;
        void *b;
};
 
// The structure only contains floats so asOBJ_APP_CLASS_ALLFLOATS should be used
struct C
{
        float x,y,z;
};
 
// The structure only contains doubles so the flags asOBJ_APP_CLASS_ALLFLOATS and asOBJ_APP_CLASS_ALIGN8 should be used
struct D
{
        double x,y;
};
 
// The structure contains union of floats so the flags asOBJ_APP_CLASS_ALLFLOATS and asOBJ_APP_CLASS_UNION should be used
struct E
{
        union {
                float x, s;
        };
        union {
                float y, t;
        };
};

It is difficult to explain exactly when one or the other should be used as it requires in-depth knowledge of the ABI for the respective system, so if you find that you really need to use these flags, make sure you perform adequate testing to guarantee that your functions are called correctly by the script engine. If neither of these flags work, and you're not able to change the class to work without them, then the only other option is to use the generic calling convention, preferably with the auto wrappers.

For compilers that don't support C++11 and asGetTypeTraits

If your compiler doesn't support C++11 features the asGetTypeTraits function will not be available. In this case you have no option but to inform the correct flags manually.

Note that the flags don't represent how the type will behave in the script language, only what the real type is in the host application. So if you want to register a C++ class that you want to behave as a primitive type in the script language you should still use the flag asOBJ_APP_CLASS. The same thing for the flags to identify that the class has a constructor, destructor, assignment operator, or copy constructor. These flags tell AngelScript that the class has the respective function, but not that the type in the script language should have these behaviours.

Observe that the C++ compiler may provide some functions automatically if one of the members of the class is of a type that requires it. So even if the type you want to register doesn't have a declared default constructor it may still be necessary to register the type with the flag asOBJ_APP_CLASS_CONSTRUCTOR. The same for the other functions.

For class types there is also a shorter form of the flags for each combination of the 5 flags. They are of the form asOBJ_APP_CLASS_CDAK, where the existence of the last letters determine if the constructor, destructor, and/or assignment behaviour are available. For example asOBJ_APP_CLASS_CDAK is defined as asOBJ_APP_CLASS | asOBJ_APP_CLASS_CONSTRUCTOR | asOBJ_APP_CLASS_DESTRUCTOR | asOBJ_APP_CLASS_ASSIGNMENT | asOBJ_APP_CLASS_COPY_CONSTRUCTOR.

// Register a complex type that will be passed by value to the application
r = engine->RegisterObjectType("complex", sizeof(complex), asOBJ_VALUE | asOBJ_APP_CLASS_CDAK); assert( r >= 0 );