Also, I should point out that you can still use pointers in 2.x, you just need to write some wrappers and register everything properly. :) One of the things I see a lot of people here fail to understand is that what the script sees and what the application sees don't need to be the same. You twist it around so the script sees just about anything.

Quote: Original post by WitchLord
I do it this way for compatibility with C++. If AngelScript didn't support native calls to C++ functions I probably wouldn't allow references at all, and only use the object handles for this purpose.

The reason for the in, out, and inout keywords is that AngelScript needs to be able to guarantee the life-time of the references, otherwise it would be possible to end up with dangling pointers. Using these keywords AngelScript will be able to make the best choices based on the need of the developer.

Regards,
Andreas

OK, but what I still don't understand :
why do you need the 'in' 'out' and 'inout' keywords ?

The way I see it, they would be implied by the definition, right ?
- 'in' would be any value that can be copied on the stack and then be used ("blah(int i)")
- 'out' and 'inout' would be a reference that is in- and/or output ("blah(int &i)")
- 'const' would define any variable that can not be changed - however you implement that.

why is the normal 'reference' definition (&) and 'const' definition (const &)
not enough to decide how to handle things ?

I think it might have to be with the fact that the script engine has no idea what C++ is going to do with the code. The script engine can guarantee that an object is not going to be destroyed/modified by function calls when those function calls only call script code. However, when your script functions call C++ code with objects that the script engine instantiated or otherwise controls, it has no idea, and will never have any idea what the C++ code is going to do with said object, thus, I believe it is forced to add this in, out, inout syntax to tell the script compiler what it should expect from the C++ code.


Am I right here WL?

Quote: Original post by WitchLord
:)

I'm aware that there are quite a few projects out there still using version 1.x because of the lack of direct pointers in AS 2.x. This is the main reason why I will do my best to introduce pointers again.

Regards,
Andreas

Wouah, this should be annouced as "best news of the day" !!!!

I will upgrade the day I will be able to do this aagain :

Direct Libc integration !

AbrKen.

LDenninger:

The problem is that &inout, which would be just & in C++, has some restrictions in AngelScript. The expression must be either an object type that support object handles, or a local variable, otherwise the life-time of reference cannot be guaranteed during the function call. I do not want to force developers to live with these restrictions for parameter references, therefore ∈ and &out are necessary to make it easier to write the script code.

∈ could be implemented as const &, but then the parameter couldn't be altered, which would be another restriction of the syntax. Not something critical though, but still.

&out cannot be implemented in C++ syntax. This one makes AngelScript pass a reference to a local temporary variable, and when the function returns the argument expression is evaluated and assigned the value of the temporary variable. It works more like an extra return value than a parameter reference.

Rain Dog is also correct in that with the in, out, and inout keywords the application can tell AngelScript what the intention of the references are so that AngelScript can make the most efficient choices.

Nothing is written in stone however, so I may change this in the future. But I'm quite satisfied with how it works right now. An alternative would be to have the following options:

Normal parameter reference - & - which would have the same restrictions that &inout has now.
Const parameter reference - const & - would work just like const ∈ do now. This would be the preferred way, at least for registered functions, as it imposes the less restrictions on the script expressions.
Out values - out - which would no longer be called a reference but to C++ it would look like a reference that it could write to.

Yet another possibility would be to allow multiple return values, but that would need a syntax completely different from C++, though there would no longer be a need for &out references.

abrken:

If atol() and similar functions are your only concern then you don't have to wait for pointers in 2.x. The bstr type is still supported in 2.x, it's just not a standard add-on because I feel that the asCScriptString is much better. You can find the implementation for the bstr type in the test_feature folder.

You could use autohandles to make sure the string is properly freed after the call.

I understand that pointers would make it easier though. :)

Regards,
Andreas

Just catching up on AngelScript happenings and seen this message. Hooray for pointers :).

I've uploaded version 2.5.0 WIP 2 of AngelScript. This will probably be the last WIP release before the final 2.5.0 version. I will at least not implement any new features in this version as I've already begun work on version 2.5.1.

New features for this WIP are:

Added support for character literals.

Added functions to the asIScriptContext interface that allow the application to enumerate variables on the stack and examine their values. (Thanks Ivan Marinov)

Added a new compile time flag: AS_ALLOW_UNSAFE_REFERENCES. When this is defined the library will allow parameter references without the in, out, or inout keywords. These parameters references will also work just like normal C++ parameter references, without any restrictions.

For the next working I will be implementing support for class methods and constructors for the script declared structures. After that I will also implement inheritance for script structures. There will also be some way of allowing script classes to inherit from application defined classes, though this will likely not work for all application registered classes.

Regards,
Andreas Jönsson


PS. Support for pointers didn't make it into this version, but I promise that they will be implemented in a not so far future. At least now you have the option to use parameter references that work the same way as in C++.