Dear subscribers, another update has been made. There's been a few changes to the interface to make it more consistent and easier to use. However, after receiving user feedback, I have kept backwards compatibility with 1.9.x. Though this backwards compatibility is only available if the library and host application is compiled with the preprocessor define AS_DEPRECATED. The methods that have changed are:

• RegisterObjectBehaviour(), it only accepts true object behaviours now, i.e. the ones that you register with the first parameter naming the object. Another method, RegisterGlobalBehaviour(), has been created for the other behaviour functions.
• GetFunctionName(), GetFunctionDeclaration(), GetGlobalVarName(), GetGlobalVarDeclaration(), GetImportedFunctionDeclaration(), and GetExceptionString() has changed to return const char * instead so that you no longer have to allocate the buffer before. The pointer that is returned is shared between these functions so you shouldn't store it for later use.
• All methods that return a string, also take an optional parameter that allow the host to get the length of the returned string directly instead of calling strlen().

I've also started to add support for multithreading. Currently this only works on Win32 and with MSVC++, but I plan on expanding this to Linux (I'll need help on that one) and MinGW. I got some strange problem when trying to support multithreading with MinGW, the code compiled ok, but when testing it would crash at inlogical places, places that haven't been changed. I think it is somehow connected to including windows.h or STL map in the code. Anyway, the support that was added for multithreading was:

• All reference counting is now threadsafe
• asGetActiveContext() is working correctly
• The shared string (mentioned above) is working by keeping a string buffer for each thread
• Created a new global function asThreadCleanup() that should be called before terminating any secondary threads that have accessed the library. If it is not called the local data allocated for the thread will be cleaned up at application exit. Note, it is not necessary to call this function in a single threaded environment.

It should now be possible to use AngelScript and access the engine and modules from multiple threads at the same time. It still very experimental, but at least rudimentary support for multithreading is now available. Please let me know if you find some trouble or wish to help me provide support for Linux and MinGW as well. I've also made a bug fix in the optimization. I had mistakedly optimized subtractions as if they were associative, this could make calculations with subtractions give the wrong result. Many thanks to Lennart Denninger for helping me find that bug. Regards, Andreas Jönsson Author of AngelScript [Edited by - WitchLord on October 31, 2004 11:05:15 AM]

One more update!!!! Way to go......glad I still have'nt updated from 1.7.x though. will take the giant step when 1.10.0 comes out

EddHead: The more you wait, more work will be necessary to do the upgrade. Although for this latest version I'm trying to keep backwards compatibility.

I didn't compile the library in release mode before uploading the latest WIP. Lennart let me know that there is some problem when doing so, but fortunately the fix is easy: Just turn on language extensions in Visual C++.

I will try to make the library fully working without Microsoft's language extensions.

I've uploaded the second WIP of version 1.10.0.

This version brings a much improved ExecuteString() method. The improvements made to the function is:
- Calls to ExecuteString() can be recursive, i.e. ExecuteString() can call a function that in turn calls ExecuteString()
- The application can pass its own context to ExecuteString() for preparation and execution (or just preparation)
- ExecuteString() should work with multiple threads (I haven't tested this yet, but I don't see why not)
- Only one call to ExecuteString() and retrieve the asIContext for exception handling (pass a pointer to a variable that will receieve the context)
- GetContextForExecuteString() is deprecated.

The old functionality is still available by defining AS_DEPRECATED when compiling the library

I've improved the multithread code so that it now works with MinGW as well. I removed the include of windows.h by locally declaring the few functions needed for thread handling. std::map had to be replaced with my own code as I found that the STL library isn't all that well-working as it ought to be. Microsoft's implementation of the STL library doesn't compile when you turn off the language extensions, and MinGW's implementation causes run-time problems with other template codes. My own map class (found in as_map.cpp) isn't quite as well structured as STL's map, but it works. However, I will improve upon it and start using it for other purposes as well, for example for mapping strings to classes, which should improve script compile times as well.

Yes, I know of STLPort which is supposedly much better than any STL library that comes with the compilers, but I don't want to force people to download another library just to compile mine. I have been thinking about rewriting the interface of my classes to match those of STL though. That would make it possible to replace my implementation and save some bytes in the final application.

I also fixed a bug with SetArguments(). It didn't allow the application to pass a pointer to the memory where the script function should return application registered classes. Thanks goes to Thomas Suter for helping me discover that bug.

Regards,
Andreas Jönsson
Author of AngelScript

It could be a bug. Can you show me an example script that crashes?

It is a bug.

What is happening is that an exception is raised because of the null-pointer access. The crash happens when SetInternalException() is called. Because the functionID for ExecuteString is 65533 there is an illegal memory access with when calling GetScriptFunction(functionID).

If you're pressed for a bug fix you could simply check for this case and skip that call.

The bug was introduced in version 1.9.1 when I took out the line numbers from the bytecode and stored them in a separate array.

Here's the complete list of bug fixes available in version 1.9.2a and 1.10.0 WIP 3:

- bug fix: Subtraction was optimized as if it was associative (thanks Lennart Denninger)
- bug fix: SetArguments() failed for script functions that returns registered object types by value. (thanks Thomas Suter)
- bug fix: The application would crash if an exception was raised in ExecuteString() (thanks Joe "Desdemona" Wright)
- bug fix: GetFunctionName() and GetFunctionDeclaration() now works for the ExecuteString() function id as well.
- bug fix: The compiler didn't warn when passing uninitialized variables to function parameters (thanks Alain "abrken" Bridel)
- bug fix: Constructors with parameters could cause assertion failure in GenerateExceptionHandler(). (thanks Alain "abrken" Bridel)

I've started work on incorporating the x86 assembler VM that Andres Carrera (Lioric) sent me. I hope to have this done by this weekend. Then we will see what kind of performance improvement we will really get.