Rain Dog:

True, with fixed multidimensional arrays the compiler can optimize the multiplication to become a simple addition.

The arrays in AngelScript are not fixed, and can therefore not use such optimizations.

desertcube:

There will be someway of setting the size of the array in the declaration, but wether this will be with string[] a(4), or string[] a = string[4], I haven't decided upon. Maybe both will work.

1. It will not be possible in this first version, but I'm looking in to allowing the application to extend the array functionality.

2. Yes the arrays are bounds checked, for security. I will not provide a way for the scripts to access the arrays without boundschecking, but the C++ application can do so if it wishes.

3. The arrays can be passed between script functions just like any other variables. The array buffer is shared between the variable instances though. Arrays can be passed to the C++ application by reference. The application will then receive a pointer to a public interface with which it will be able to manipulate the arrays. Because the array object relies on information registered in the engine it will not be possible to move the array outside the engine. And certainly not between engines.

You can only pass a C++ vector to the scripting engine by registering a object type for it. I'm planning to allow the application to register special array objects that will replace the default array. To the script there will be no difference between these special arrays and the default array but the application will be able to receive the array object in the form it wishes (e.g. std::vector).

I've also been thinking about a way to allow the application to register a function parameter with a special modifier. When the script passes an array to a parameter that has this modifier the engine automatically calls a method to retrieve the internal buffer pointer from the array. That will allow you to receive a normal C++ pointer to an array without any special work.

It is a simple array/vector. Nothing fancy.

A more complex structure, such as a map, can easily be registered by the application so I don't think I need to supply it in the library by default.

My goal with version 1.10.0 is the support for simple arrays of any type. It was the one major language feature missing from the library in my opinion. With the arrays AngelScript has everything that a basic language has. From here I will move into a higher level with structures and eventually classes with inheritance, polymorphism, etc.

Right now, you can already register any stl container, with the problem that you have to re-register a unique type for every kind of thing you want to stick in them. I'm doing it. With a bit of template and macro trickery, you can automagically register a vector of any type.

Create a function of the form 'template <class T> registerVector(std::string type_name)' that does the actual work of registering the type, and a macro such as '#define RegisterVector(A) { registerVector<A>(##A); }' to invoke it properly. The code to register the type then becomes 'RegisterVector(TypeName)'. Don't expect this to work in MSVC6.0 - for that, you'll need to include a paramter of type T in the template function, and modify the macro to declare and supply it. I think I'm going to go do this, right now. :D Any suggestions on how I should format the typename I register with angelscript?

It's not as hard as you think. Right now, I am just wrapping up my vectors in global functions. I am working on some auto-binding code, though.



That will register the vector, and angelscript will be able to properly create and destroy them. Of course, they won't -do- anything. I just started working on this, what, half an hour ago? I have an idea of how to do the behavior. It's going to rely on the user registering the contained-type before registering the vector.

This will be a very good add-on code for the library. If you make it real nice looking I would like to distribute it in the standard download, just as I do with the bstr and std::string add-on.

I will make AngelScript allow the registration of array objects that override the native array. For the script writer this will be transparent, but the application will be able to receive the exact object type that it wants to work with. The registered array object will most likely be faster than the native array as well, as the native array is completely dynamic and needs to look up the contained object's methods as it is constructed, destroyed, or resized.

Since Angelscript's arrays are dynamic, vector doesn't add anything angelscript can't already do. In fact, as soon as you get script-defined classes working, I could liberally apply my pre-processor and create generic lists right in angelscript itself. Macros can go a long way towards mimicing templates.

But I will see if I can produce a generic vector binder for you. Any particular features you are looking for?