Jump to content

  • Log In with Google      Sign In   
  • Create Account

Sir Ementaler

Member Since 09 Mar 2013
Online Last Active Today, 01:42 PM

Posts I've Made

In Topic: AngelScript execution speed?

20 October 2016 - 06:29 PM

If AngelScript were as fast as your initial post claims it to be, i.e. 2.5 times slower than C++, it would likely be the fastest scripting language known to man. If, when bringing up Lua, you're thinking of this benchmark, take some time to actually read what it says and you'll find out that AngelScript performance was tested without a JIT compiler and compared against JIT-compiled Lua. Not to discredit the author, as neither could I get the only known AngelScript JIT compiler to work, but that is not a fair fight. Putting AngelScript up against C++, a language designed from the beginning to end to be efficient, whose compilers had decades to improve their optimization, is even less of a fair fight. Perhaps you ought to consider that the intended use of AngelScript does simply not require great speed. You're not supposed to use it to carry complicated calculations and find undiscovered prime numbers; it's a scripting language, use it to make things happen in games and stuff.

In Topic: Assigning property without a setter

20 October 2016 - 11:15 AM

If your class is registered in a way as straightforward as you present it, the most reasonable thing to do would be to register the property as a non-virtual property. Getters and setters are only useful if it is unsafe to access the variable directly. If a setter is necessary because a change to the property may have side effects, then, well, you need a setter. AngelScript supports variable type functions but type compatibility is not verified at compile time, i.e. the function would accept arguments of any type. I don't recommend this for cases where the number of supported types is finite, but if it works for your purposes, you can read about it here. Otherwise you will unfortunately have to register multiple setters. That said, I'm not sure why you're so opposed to this idea, as you can do this without much work using a couple of C++ templates. Our project does this for a couple of methods with >10 overloads.

In Topic: Problem in array<interface@>

10 September 2016 - 03:23 AM

Yes, but that doesn't relate at all to what I claimed. Notice how in C++ too, the signature "int find(const T&)" for T = int* would become "int find(int* const&)" and not "int find(const int*&)". Instantiation of a template is more than just replacing every "T" with the type name. You should be checking the signature for the type array<Item@> if you want to determine anything.

In Topic: Problem in array<interface@>

06 September 2016 - 03:55 AM

Yes I agree on 100% that it's unnecessary to pass handles by &in reference.

But such signature is a part of ScriptArray addon API: when we create a variable of

type array<IItem@> the find method

(whose signature is int find(const T&in if_handle_then_const value) const)

will actually have the find(const IItem@ &in if_handle_then_const value) const signature.

It seems there is no any method to avoid such a situation in array<>.


To my information, that is incorrect. If you attempt to query the signature of the method, it's actually "int array::find(Item@const&in value) const" (or likely "int array::find(const Item@const&in value) const" in the WIP version I am not using). Notice the const qualifier in front of "&in", meaning that the handle should be passed by const &in reference rather than just &in, and thus it's possible to avoid creating a copy of the handle. The same signature would not be considered valid in other contexts, i.e. outside of templates. As such, outside of templates it is unnecessary and actually somewhat inefficient to use the signature you're using.

In Topic: Problem in array<interface@>

04 September 2016 - 02:56 AM

That appears to be some sort of a side effect, possibly a bug, of passing the handle by non-const &in reference. There is no good reason whatsoever to pass handles by &in reference. A signature such as "int32 getIndexOf(const IItem@ hItem)" should work correctly.