After an unusually long period a new version is finally out. This version comes with a number of smaller enhancements. Too many to list here, so if you want details, please check the change list.

The most important improvements are the following:

A new flag to support C++ array types: asOBJ_APP_ARRAY. This flag introduced for C++ types like the following: 'typedef float vec3f[3]', as this kind of types didn't follow the ordinary calling convention for classes nor primitives.

Thanks to GGLucas the script language now supports named arguments when calling functions. This means that you can now call a function using the following syntax: 'func(arg1 = expr, arg2 = expr2)' and so on. When this is done, the compiler will rearrange the arguments by their names so that the order matches the declaration. This works especially well together with default arguments, as you will be able to provide only a few of the arguments, leaving the rest with the default value.

Also thanks to GGLucas the script language now supports auto types in variable declarations with initialization expressions. Just like in C++ the compiler will deduce the type of the variable from whatever type the expression evaluates too.

I've implemented a new operator overload 'opHndlAssign'. Types registered with asOBJ_ASHANDLE should use this operator overload instead of the ordinary 'opAssign' to implement the handle assign operation. This together with an enhancement to asBEHAVE_VALUE_CAST to allow the generic form 'void f(?&out)' has allowed me to implement a nicer syntax for managing the values in the dictionary add-on:

int val = int(dict['value']);
dict['value'] = val + 1;
obj @handle = cast<obj>(dict['handle']);
if( handle is null )
  @dict['handle'] = object;

This should lend itself well for implementing a true 'variant' type. Perhaps that's even something I'll try for an upcoming release.

The engine has a couple of new callbacks calls RequestContext and ReturnContext. These callbacks can be used to implement context pooling for better performance, and they can also be used to pre-configure contexts that will be used internally by the engine, e.g. to debug script class destructors called from the garbage collector.

Jordi Oliveras Rovira has taken the time to implement support for functor calling conventions asCALL_THISCALL_OBJFIRST and asCALL_THISCALL_OBJLAST. These work similarly to the existing asCALL_THISCALL_ASGLOBAL where the application supplies the a pointer to the functor object that emulates the function/method that the script calls. With this it is now perfectly possible to use for example std::function to implement proxy/wrapper functions if so desired.

Regards,

Andreas

I presume you're referring to the new asOBJ_APP_ARRAY flag.

This doesn't affect the array add-on. It is only used when registering value types, i.e. together with asOBJ_VALUE. Here's an example:

typedef float vec3f[3]; 
 
vec3f AddVec3(vec3f a, vec3f b) {
  vec3f r = {a[0]+b[0], a[1]+b[1], a[2]+b[2]};
  return r;
}
 
void RegisterVec3(asIScriptEngine *engine)
{
   engine->RegisterObjectType("vec3", sizeof(vec3f), asOBJ_VALUE | asOBJ_POD | asOBJ_APP_ARRAY);
   engine->RegisterObjectProperty("vec3", "float x", 0);
   engine->RegisterObjectProperty("vec3", "float y", 4);
   engine->RegisterObjectProperty("vec3", "float y", 8);
 
   engine->RegisterGlobalFunction("vec3 add(vec3, vec3)", asFUNCTION(AddVec3), asCALL_CDECL);
}
 
 

Without the asOBJ_APP_ARRAY AngelScript wouldn't know exactly how to handle this type when passing it by value to an application registered function, or receiving it by value, so the application developer had to resort to wrappers when dealing with this kind of types.

How these flags should be used and why are also described in the manual here: <a href="http://www.angelcode.com/angelscript/sdk/docs/manual/doc_register_val_type.html#doc_reg_val_2">

Value types and native calling conventions</a>

I've decided to change the syntax for named arguments to use : instead of =. This is done in revision 1973.

Why did I make this decision? Well, because of the following situation:

void func(int val)
 
void main()
{
  int val;
  func(val = 1); // What would this really do?
}

Yes, I suppose that would be possible.

Correct. The bytecode is not affected by this.

However you should never rely on pre-compiled bytecodes to be compatible between differents versions of AngelScript. There is no defined file format for the pre-compiled bytecode that is being maintained between SDK versions.

I've implemented the engine property asEP_ALTER_SYNTAX_NAMED_ARGS to optionally support the previous syntax for named arguments. It has 3 values:

0 = no support for old syntax (default)

1 = support old syntax but warn if detected

2 = support old syntax without warnings

This is available in revision 1974.