Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

Sir Ementaler

Member Since 09 Mar 2013
Offline Last Active Mar 08 2015 03:49 AM

Posts I've Made

In Topic: Angelscript Operators

03 January 2015 - 11:39 AM

Ah yes, I absolutely agree something like Phoenix would be an overkill and not what a scripting language should aim to support, it just happened to be the only good usage of non-Boolean comparison operators I could recall. It's really nice to hear that lambda functions will become available too, I'm really looking forward to that.

In Topic: Angelscript Operators

03 January 2015 - 07:01 AM

I can think of two potential applications of separate comparison operators. One is the case of types for which trichotomy does not hold, such as ones in which comparisons are to be based on float comparisons (where the relations between two values can be either less than, equal, greater than or unordered). In this case, a programmer may want to code operator overloads in such a way that, for unordered values, ==, <, >, <= and >= return false while != returns true. This isn't currently entirely possible, but probably could be accomplished without separate operator overloads, e.g. if opCmp was allowed to return a float instead of int (then it could return NaN in case of unordered comparisons). Speaking of which, however, I also recall that, even in primitive float types, comparisons between unordered values fail to return correct results in AngelScript. I even remember having observed strange behavior where const float NaN behaved differently in comparisons than non-const float NaN but I don't remember the details and I've been testing it a few releases ago so things might've changed.

The other scenario that comes to mind is when one wants to create lazy operators with use of functors, like it was done in Phoenix. In this case, all comparison operators would be expected to return a functor rather than a bool, effectively making any default implementation of part of the operators impossible. However, AngelScript is probably missing far more than just that in order to make those functors possible and useful; I'd predict huge difficulties in the template department for a start, with no such thing as C++'s std::function.

In Topic: Bug in type-casting

13 December 2014 - 04:39 AM

From your code it looks like your problem is much more prosaic in nature: you're probably trying to call a non-const method on a const handle. That is what the error indicates (no matching signatures to 'Label::setText(string) const') and it's why the other part of your code works ("const Widgets::Label @mClock" vs "Widgets::Label @Clock").

In Topic: Including namespace on GetTypeDeclaration()

05 November 2014 - 01:52 AM

I had a similar issue recently involving asIScriptFunction::GetDeclaration. While personally I certainly don't mind it explicitly stating the global namespace, it appeared as if asIScriptModule::GetFunctionByDecl was unable to interpret it. That means that neither including nor omitting the namespace always allows for identification of a function. Additionally, in this case the redundant "::" could prove more difficult to find and remove if one were to do that by hand, because it doesn't directly precede the string (and there could potentially be more occurrences of it, e.g. consider "foo::bar ::function(foo::bar)"). What I ended up doing was

asFunction->GetDeclaration(true, asFunction->GetNamespace()[0] != '\0', false)

which, honestly, looks like a terrible hack, but works. Either way, if not getting rid of the explicit preceding scope resolution operator, I would suggest at least modifying GetFunctionByDecl and possibly other similar functions accordingly, as they should most certainly be able to interpret declarations returned by other library functions.

In Topic: Default constructors vs default arguments

23 August 2013 - 07:14 AM

I'm almost entirely convinced that if somebody creates a constructor that can be called without any arguments, their intention is making it a default constructor. I was trying to imagine a case in which this could generate problems but I'm unable to. I'm pretty sure a constructor whose all arguments have default values should overtake all functions of a default constructor including creating temporary objects, even if only because creating a proper default constructor would become impossible due to a "multiple matching signatures" error. I'm not as experienced programmer and I won't be surprised if I had overlooked some downside of this solution so if you could explain why exactly it sounds like a bad idea, I would be thankful.