Jump to content

  • Log In with Google      Sign In   
  • Create Account

Andreas Jonsson

Member Since 26 Mar 2000
Offline Last Active Today, 12:39 PM

#4989824 How to disable - Caught an exception from the application

Posted by Andreas Jonsson on 13 October 2012 - 11:24 AM

Compile the library with AS_NO_EXCEPTIONS and AngelScript won't catch exceptions from the application.


#4988913 16 Byte Alignment on Value Types

Posted by Andreas Jonsson on 10 October 2012 - 06:54 PM

So far the only way to guarantee memory alignment is with scoped reference types.

I have plans to add support for per-type memory alignment with registered types, but it is not an easy thing to do, and is quite low on my priorities.

#4987420 registering specialized template class?

Posted by Andreas Jonsson on 06 October 2012 - 09:47 AM

The registration was failing because the LLObject template type didn't have a default constructor, which AngelScript treated as if the template type cannot be instanciated at all.

I've fixed this in revision 1424.

#4987411 Mixin in different section compile error

Posted by Andreas Jonsson on 06 October 2012 - 09:15 AM

This has been fixed in revision 1423.


#4986979 registering specialized template class?

Posted by Andreas Jonsson on 04 October 2012 - 07:28 PM

It might be a bug in AngelScript when parsing the template specialization with the handle as subtype. I'll investigate it.

#4986616 Mixin in different section compile error

Posted by Andreas Jonsson on 03 October 2012 - 07:14 PM

Thanks. This problem has already been reported by another user. I'll have it fixed asap.

#4986610 CreateUninitializedScriptObject return null for type of array<int>

Posted by Andreas Jonsson on 03 October 2012 - 06:53 PM

Jake's correct. CreateUninitializedScriptObject only works for script classes, and not for registered types. AngelScript wouldn't know how to safely create an uninitialized instance of a registered type.

#4982560 More advanced parsing & script section order

Posted by Andreas Jonsson on 21 September 2012 - 09:17 PM

The order of the script sections doesn't matter to AngelScript. The only thing that matters is that a script section added to AngelScript only contains fully declared entities, i.e. you cannot declare part of a class or a function one section and the other part in another section.

Sequential pre-processing commands were not on my mind when I implemented the script builder add-on. To support sequential pre-processing commands the includes would probably have to be pre-processed as they are found. This would likely make the add-on more complex.

The token definitions used internally by AngelScript are not exposed to the application, so there is no way to get them without modifying the library. The ParseToken() method can quite easily be modified to return the token definition. What exactly do you want this for?

#4982436 Using AngelScript namespace causes linker error (VC11)

Posted by Andreas Jonsson on 21 September 2012 - 11:15 AM

It's better to define AS_USE_NAMESPACE on the project settings, rather than in the code. Otherwise it is very easy to forget it in some places which makes part of the code refer to AngelScript functions without the namespace, and others with it, which is sure to cause linker errors.

In your case the namespace got declared when you included the scriptstdstring.h, thus the code sees the RegisterStdString() as part of the namespace. On the other hand, when the scriptstdstring.cpp was compiled the namespace was not declared, so RegisterStdString() was implemented outside the namespace.

#4982076 Delegates in AngelScript

Posted by Andreas Jonsson on 20 September 2012 - 10:21 AM

It's tricky, but can be done similarly to how the property accessors are evaluated already, i.e. the decision to use either set or get needs to be deferred until the very last moment when it can be determined which function signature the delegate is expecting.

#4981074 AngelScript 2.25.0 is here

Posted by Andreas Jonsson on 17 September 2012 - 06:35 PM

It's time for a new release. This new version brings 4 principal improvements:
  • Improved build performance for large scripts. This improvement is mostly thanks to Markus Lenger's contribution of symbol tables that provides binary searches for symbols. Other optimizations throughout the code also helped improve compilation times.
  • The introduction of 'mixin classes' in the script classes. The mixin classes gives an easy way to provide default implementations of common methods and properties for script classes, where single inheritance is not enough.
  • The interface has received new methods to better support script function handle from the application side. It was for example quite cumbersome to initialize a CScriptHandle from the application side with a function handle.
  • The bytecode can now optionally be saved without debug information, such as the name of script sections, local variables, and line numbers. Stripping of debug information can significantly reduce the size of pre-compiled bytecode.
Besides those main improvements there is a list of bug fixes and minor improvements as well that you'll find in the change list.


#4977640 AngelScript mixin classes - preview

Posted by Andreas Jonsson on 07 September 2012 - 08:23 AM

I've fixed that null pointer access in revision 1409. Thanks.

I'm glad you like how it works so far.

I'll make further improvements in the future, i.e. ability to implement interfaces, include other mixin classes, and possibly even add support for constructors and destructors to mixin classes.

#4977476 Function call operators in the future?

Posted by Andreas Jonsson on 06 September 2012 - 09:22 PM

CompileVariableAccess() is pushing the object pointer on the stack. The code just need to make sure to dereference it if necessary.

Test compiling a script that calls the opCall method explicitly and you'll see what needs to be done.

class Class
  void opCall() {}
void main()
  Class c;
  c();              // This should produce the exact same bytecode as the next line


The temp variable for the funcdef is to make sure function object stays valid throughout the function call. Otherwise a script like this might crash:

funcdef void FUNC();
FUNC @func = CompileFunction("void myfunc() { @func = null; }");
void main()

It's obviously a very stupid example, but since AngelScript is supposed to be sandboxed, even stupid examples must not crash.


The first call to CompileVariableAccess() must not return global variables, otherwise those will be found before the class methods of the same name. Let's say you have the following script:

funcdef void FUNC();
FUNC @func;
class Class
  void func() {}

  void method()
     func();           // <-- func is a class method and a global function pointer, both match, but the class method is seen first 

If the first call to CompileVariableAccess() would find the global variable then Class::method() would call the wrong function.

It looks like there might be a bug here. I need to verify, but it looks like the first call to CompileVariableAccess() currently will find matching global variables. If so I'll have to fix that.

#4977400 Function call operators in the future?

Posted by Andreas Jonsson on 06 September 2012 - 04:41 PM

In case of an implicit this pointer, i.e. when a class method is called from within another method, the CompileFunctionCall() pushes the this pointer onto the stack after it has determined that it is a class method that is being called. You'll find the following code, early in the CompileFunctionCall()

   // The object pointer is located at stack position 0
   ctx->bc.InstrSHORT(asBC_PSF, 0);
   ctx->type.SetVariable(dt, 0, false);

When it is not an implicit this pointer, then the object pointer is pushed on the stack in CompileVariableAccess() (look for THIS_TOKEN). In this case the compiler will go through the CompileExpressionPostOp where the . operator (if( op == ttDot )) case will invoke the CompileFunctionCall().


#4974442 Using const char*

Posted by Andreas Jonsson on 29 August 2012 - 08:44 AM

A couple of changes in the library is needed:

as_callfunc.cpp, function PrepareSystemFunction(), around line 325:

   // It's not safe to pass objects by value because different registers
   // will be used depending on the memory layout of the object
   // Ref: http://www.x86-64.org/documentation/abi.pdf
   // Ref: http://www.agner.org/optimize/calling_conventions.pdf
	   !(func->parameterTypes[n].GetObjectType()->flags & COMPLEX_MASK) &&
	   func->parameterTypes[n].GetSizeInMemoryDWords() < AS_LARGE_OBJ_MIN_SIZE &&
-       !(func->parameterTypes[n].GetObjectType()->flags & (asOBJ_APP_CLASS_ALLINTS | asOBJ_APP_CLASS_ALLFLOATS)) )   
+       !(func->parameterTypes[n].GetObjectType()->flags & (asOBJ_APP_PRIMITIVE | asOBJ_APP_FLOAT | asOBJ_APP_CLASS_ALLINTS | asOBJ_APP_CLASS_ALLFLOATS)) )
    engine->WriteMessage("", 0, 0, asMSGTYPE_INFORMATION, func->GetDeclarationStr().AddressOf());
    asCString str;
    str.Format(TXT_DONT_SUPPORT_TYPE_s_BY_VAL, func->parameterTypes[n].GetObjectType()->name.AddressOf());
    engine->WriteMessage("", 0, 0, asMSGTYPE_ERROR, str.AddressOf());
    engine->ConfigError(asINVALID_CONFIGURATION, 0, 0, 0);

and in

as_callfunc_x64_gcc.cpp, function CallSystemFunctionNative(), around line 290:

   // An object is being passed by value
   if( (descr->parameterTypes[a].GetObjectType()->flags & COMPLEX_MASK) ||
	   descr->parameterTypes[a].GetSizeInMemoryDWords() > 4 )
    // Copy the address of the object
    argsType[argIndex] = x64INTARG;
    memcpy(paramBuffer + argIndex, stack_pointer, sizeof(asQWORD));
-   else if( descr->parameterTypes[a].GetObjectType()->flags & asOBJ_APP_CLASS_ALLINTS )
+   else if( (descr->parameterTypes[a].GetObjectType()->flags & asOBJ_APP_CLASS_ALLINTS) || (descr->parameterTypes[a].GetObjectType()->flags & asOBJ_APP_PRIMITIVE) )
    // Copy the value of the object

I'll have these changes checked in as soon as possible.