Factory function

The factory function is the one that AngelScript will use to instantiate objects of this type when a variable is declared. It is responsible for allocating and initializing the object memory.

The default factory function doesn't take any parameters and should return an object handle for the new object. Make sure the object's reference counter is accounting for the reference being returned by the factory function, so that the object is properly released when all references to it are removed.

CRef::CRef()
{
    // Let the constructor initialize the reference counter to 1
    refCount = 1;
}
 
CRef *Ref_Factory()
{
    // The class constructor is initializing the reference counter to 1
    return new CRef();
}
 
// Registering the factory behaviour
r = engine->RegisterObjectBehaviour("ref", asBEHAVE_FACTORY, "ref@ f()", asFUNCTION(Ref_Factory), asCALL_CDECL); assert( r >= 0 );

You may also register factory functions that take parameters, which may then be used when initializing the object.

The factory function must be registered as a global function, but can be implemented as a static class method, common global function, or a global function following the generic calling convention.

Even though a factory function returns an object handle, it must not return a null handle unless it also sets an exception to signal that the instantiation of the object failed.

The behaviour is undefined if a factory function returns null without setting an exception.

Addref and release behaviours

void CRef::Addref()
{
    // Increase the reference counter
    refCount++;
}
 
void CRef::Release()
{
    // Decrease ref count and delete if it reaches 0
    if( --refCount == 0 )
        delete this;
}
 
// Registering the addref/release behaviours
r = engine->RegisterObjectBehaviour("ref", asBEHAVE_ADDREF, "void f()", asMETHOD(CRef,AddRef), asCALL_THISCALL); assert( r >= 0 );
r = engine->RegisterObjectBehaviour("ref", asBEHAVE_RELEASE, "void f()", asMETHOD(CRef,Release), asCALL_THISCALL); assert( r >= 0 );

If the instances of this object will be shared between multiple threads, remember to guarantee that the reference counter is thread safe by making the increments and decrements with atomic instructions.

See also: Multithreading

Reference types without reference counting

If the application provides its own memory management that isn't based on reference counting, then it is possible to register the type without the addref and release behaviours if the flag, asOBJ_NOCOUNT is informed in the call to RegisterObjectType, i.e.

// Registering the reference type

r = engine->RegisterObjectType("ref", 0, asOBJ_REF | asOBJ_NOCOUNT); assert( r >= 0 );

Without the addref and release behaviours the application must be careful to not destroy any objects that may potentially still be referenced by the script engine, e.g. in a global variable, or other location.

Unless the objects are guaranteed to stay alive as long as the script engine is instantiated, you may want to consider disabling global variables with engine property asEP_DISALLOW_GLOBAL_VARS. This will make it much easier for the application to know where references to the objects are kept. An alternative to disabling all global variables, is to selectively disallow only the global variables, that can eventually store a reference to the object type. This can be done by enumerating the compiled global variables after script has been built and giving an error to the user in case he includes a variable he shouldn't.

List factory function

The list factory function is a special factory function that can be registered to allow a type to be created from an initialization list. The list factory function takes only a single pointer as argument. AngelScript will pass a pointer to the initialization list buffer in that argument. The buffer will contain all the values necessary to create and initialize the object.

In order for the script engine to know what information must be placed in the buffer the application must provide the list pattern when registering the list factory. The list pattern is declared with a special syntax involving datatypes and the following tokens: {, }, ?, repeat, and repeat_same.

The tokens { } are used to declare that the list pattern expects a list of values or a sublist of values. The repeat token is used to signal that the next type or sub list can be repeated 0 or more times. The repeat_same token is similar to repeat except that it also tells the compiler that every time the same list is repeated it should have the same length. Any data type can be used in the list pattern, as long as it can be passed by value. When a variable type is desired the token ? can be used.

Here's a couple of examples for registering list factories with list patterns:

// The array type can be initialized for example with: intarray a = {1,2,3};
engine->RegisterObjectBehaviour("intarray", asBEHAVE_LIST_FACTORY, 
  "intarray@ f(int &in) {repeat int}", ...);
 
// The dictionary type can be initialized with: dictionary d = {{'a',1}, {'b',2}, {'c',3}};
engine->RegisterObjectBehaviour("dictionary", asBEHAVE_LIST_FACTORY, 
  "dictionary @f(int &in) {repeat {string, ?}}", ...);
  
// The grid type can be initialized with: grid a = {{1,2},{3,4}};
engine->RgisterObjectBehaviour("grid", asBEHAVE_LIST_FACTORY,
  "grid @f(int &in) {repeat {repeat_same int}}", ...);

The list buffer passed to the factory function will be populated using the following rules:

Whenever the pattern expects a repeat, the buffer will contain a 32bit integer with the number of repeated values that will come afterwards
Whenever the pattern expects a ?, then the buffer will contain a 32bit integer representing the typeId of the value that comes after.
Whenever the pattern expects a reference type, the buffer will contain a pointer to the object
Whenever the pattern expects a value type, the buffer will contain the object itself
All values in the buffer will be aligned to a 32bit boundary, unless the size of the value placed in the buffer is smaller than 32bits.

See also: array template object and dictionary object for example implementations of list factories.

Registering an uninstantiable reference type

Sometimes it may be useful to register types that cannot be instantiated by the scripts, yet can be interacted with. You can do this by registering the type as a normal reference type, but omit the registration of the factory behaviour. You can later register global properties, or functions that allow the scripts to access objects created by the application via object handles.

This would be used when the application has a limited number of objects available and doesn't want to create new ones. For example singletons, or pooled objects.