native array support

Hey Rain Dog,

Quote:

I will now concentrate on implementing support for native arrays, and also writing testcases to cover the rest of the bytecode instructions.

This is a quote taken from the WIP 3 thread here .

Can't wait for this myself, it's been the one thing preventing me from committing completely to AS since I first started lurking here around v1.7 :)

I'd also just like to say, keep up the great work Andreas! ;) I'm amazed by how much progress you've managed to make in the last few weeks. Can't wait to get back into this again.

Cheers!

Adam

Yes, I'm working on it right now. It is the main goal with version 1.10.0. There's been a lot of other improvements that made it in to 1.10.0 before the arrays, but that is only because they were much easier to implement.

I hope I can finish the arrays until the end of the month, but I can't promise anything.

Sounds good.

Development of the arrays have progressed well during these last few days. This weekend I hope to release a WIP with working single dimensional arrays (working but severly limited).

I have seen that struct/class are the next task in WIP.

Do you think (Andreas) that implementing struct would be a difficult task ?

I'm asking this because I'm waiting for beeing able to store arrays of structs that have been defined in AS.

if it is an array of structs or classes, i am assuming that with native array support you would be able to create an array of pointers, and then you would just have to register ->

Is this correct?

Also, i have a question about the array implementation: Multiple dimensions are one dimensional arrays with a neater syntax:

int array[5][10];
int *mp = array;

*(mp + 10) == array[1][0]

abrken:

I'm almost certain that I will come upon problems while developing the structs, but I'm absolutely certain that I will be able to overcome them. For simple structs I don't think there will be too much problems, but when I start including inheritance of C++ classes I'm sure there will be some difficulties. The biggest problem with script declared structs is their constructor/destructor, but I believe I have that covered.

I'm hoping to have simple structs without methods implemented by the end of November. I'll have to see then what I'll do next.

Rain Dog:

An array will be able to store any object that you can store locally on the stack. Thus an array of pointers is possible.

Because each array is an object in itself it is difficult to make that optimization for multiple dimensional arrays of fixed sizes. But I will see what can be done. For now, you'll have to do it manually, but doing the multiplication before accessing the single dimensional array.

It's now possible to execute scripts like this:



As you can see, there are a few differences from C++ arrays. The first is how the array object is declared:

"string[] a;" instead of "string a[];"

I decided to do it like this, because it was easier, and I think it makes sense to think of the array as a separate type, not a type modifier. Also it's not possible to set the size of the array directly in the declaration. I'm thinking of having a constructor that takes an integer to do that, but this hasn't been decided yet.

string[] a(5);

I had initially thought to make the array object an externally registered object, just like the string object. But since the array object must be able to work with all object types this wasn't possible. I may allow the application to register specialized array objects, that override the default array for that data type.

There are a few things that I need to clean up before I can release this WIP, but everything is on track for a release this weekend.

Quote:

Original post by Rain Dog if it is an array of structs or classes, i am assuming that with native array support you would be able to create an array of pointers, and then you would just have to register -> Is this correct? Also, i have a question about the array implementation: Multiple dimensions are one dimensional arrays with a neater syntax: int array[5][10]; int *mp = array; *(mp + 10) == array[1][0]

*(mp + 10) == array[1][0]

there is no multiplication there, it is indirection and pointer arithmetic that is the equivalent of using bracket notation []

OK, just a suggestion on the syntax. Could you have something like this:

string [] a = string[5];

Not sure how easy that is to implement, but I think it doesn't look too bad. While I’m posting, I may as well ask a few questions about the actual array's.

1. Will you be able to add stuff to the end (i.e. std::vector push_back)
2. Are they bound checked? If so, is there an option to disable it (perhaps a special function call?)
3. How would we be able to pass them between functions? In C++ you use pointers, but what about in AS? Also, will you be able to pass C++ arrays (or vectors, I hardly ever use array's) to the AS program and vice versa?

Sorry for all the questions, I'm just being curious on their limitations.

Anyways, keep up the good work!

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.

What kind of data structure are you using for the arrays? Are it vectors, deques, ...? It would also be intersting to provide map support with custom defined index type (strings, for example). This is probably too much to ask for for, so I'm expecting this in this (or the next) version.

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 registerVector(std::string type_name)' that does the actual work of registering the type, and a macro such as '#define RegisterVector(A) { registerVector(##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?

Deyja, can you include a sample of this?

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?

My needs for a vector are really simple.

I need a vector and a vector< vector >

I am entirely too unfamiliar with the way that binding these objects in angelscript works.