I don't think it is because of anything malloc does. More likely the debug build uses different instructions to load the SIMD registers so the __m128 types doesn't require alignment. This is however something that would be in your application, and not in AngelScript.
You can set custom memory functions with asSetGlobalMemoryFunctions(). With this the application can use memory routines that is guaranteed to always return 16byte aligned memory to the script library. You probably don't want to use 16byte aligned allocations for everything though, as it will waste a lot of memory when the allocations are smaller than 16bytes.
This gave me an idea. The code in as_memory.h can perhaps be enhanced to have a new macro for allocating 16byte aligned memory, e.g. asNEW16 and asNEWARRAY16. This macro can then call a new userAlloc16 global function. The pieces of code I mentioned above that need to guarantee 16byte aligned memory would then only have to call these macros instead of the existing ones to allocate the memory.
With the current version of AngelScript I can think of two ways of solving this.
1. By having some function for retrieving the existing object from the application, through a lookup. You can then have your 'secret' global variables call this function as part of their initializations.
// Secret Global Section
const MyLinkedType@ v1 = __GetExistingObject('whatever');
// User section
const MyLinkedType@ u1 = v1
const MyLinkedType@ u2 = v1
if (u1 is v1)
else if (u2 is v1)
return 2; // This is what returns.
2. Register the 'secret' global variables from the application, instead of declaring them as part of the script. You can use dynamic configuration groups to unregister the global variables in case they change.
As a future enhancement to better support what you want I can think of 2 solutions:
1. Allow resetting global variables selectively. The application could then manually initialize some of the global variables like you currently do, and mark them as finished. Then call ResetGlobalVars to have the script engine initialize the remaining variables.
2. Implement the already planned export-import feature. With this you could compile the secret global variables in a separate module and mark them for export. The user written module will then import the global variables already pre-initialized.
I've finished incorporating these improvements into the WIP version. (revision 1779).
With the improvements I see an average improvement of around 30% in the compilation times.
I didn't include the changes as-is, so when you pick up the new version you'll will not see exactly the code you provided, but you should see that all the improvements you made has made it into the code, and in some cases I made further improvements on top of them.
Currently you would need to keep the CScriptBuilder around. Or extract the metadata to store it in some other form. With the change I proposed, the metadata could for example be stored as user data in the script code (actually, it can already be done that way, unless you're already using the user data for something else).
The metadata for classes should preferably be stored with the asIObjectType, and not the asIScriptObject. After all, the metadata is part of the code, and not the instances.
With this version I've spent a lot of time to redesign how the initialization lists work. Previously they could only be used for arrays, but now the application can register a list factory, or list constructor for value types, and declare a pattern that should be used by the compiler. The compiler will also build a single buffer with all the value and pass a pointer to that buffer to the factory or the constructor. This makes it much more effective to copy the values into the object in comparison with the previous use of the index operator.
The new initialization lists are a lot more versatile, and I've used this to implement a list factory for the dictionary add-on that takes name-value pairs, and also a list constructor for the complex math type to show how it is done.
Hopefully this will make AngelScript much more useful as a data language, i.e. where the scripts are used to setup data besides just for logic.
There is of course a lot more than can still be improved with regards to the initialization lists, and I'll continue to work on this over the upcoming releases. Some examples of future improvements are the ability to use initialization lists in regular expressions, and more rules that can be given to declare the expected list pattern.
The release brings several other minor improvements too, so please verify the change list to get the details.
I guess I'll have to rewrite the tutorial article. It was meant to describe how to do things not to be copied and pasted into an application
I suggest you take a look at the sample applications. Those can be compiled and tested. I've tried to comment the code in them as well as possible so you shouldn't have problems understanding from them.