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 Today, 10:58 AM

Topics I've Started

Errors produced by classes in namespaces accessing global properties

03 March 2015 - 04:08 PM

Using AngelScript 2.30.0, I encountered these two today:


An unjustified compile time error when a method of a class in a namespace calls a function with an argument that defaults to a global variable:

int i;
void f(int a = i) {}
namespace n {
 class c {
  void m() {
script.as (5, 3) : INFO : Compiling void c::m()
default arg (1, 1) : ERR : 'i' is not declared
script.as (6, 4) : ERR : Failed while compiling default arg for parameter 0 in function 'void f(int = i)' 

An unjustified compile time error when a class in a namespace has a property that defaults to a global variable:

int i;
namespace n {
 class c {
  int p = i;
script.as (3, 8) : INFO : Compiling c::c()
script.as (4, 11) : ERR : 'i' is not declared

The errors disappear if "::" is added in front of "i" in the appropriate places in the above examples but given the conditions it shouldn't be required (and, in the former case, may be impossible to add from script level if the function in question is registered by the application).

Error for non-default namespace interfaces used in methods of mixin classes inherited f...

21 January 2015 - 03:06 PM

I just couldn't help but make the title comprehensive.

Here's an example piece of code that, tested in AngelScript 2.29.2, causes a compilation error that shouldn't happen:

namespace n {
	interface i {}
	mixin class m {
		void f(i@) {}
class c : n::m {}

The error reads:

ERR : Identifier 'i' is not a data type in global namespace

...which is irrefutably true, but hardly justifying. Handles to the interface can be used correctly as members of the mixin class but an attempt to use them as method arguments or other local variables in methods will make the compiler try to use types defined in the global namespace (or whatever the namespace of the class named "c" in the example is). It goes without saying that this may have bad consequences if, for example, both the local and global namespaces contain an interface named "i" and the mixin class is registered as:

mixin class m {
	i@ foo;
	void f(i@ bar) {
		@foo = @bar;

Such code will generate a rather hilarious error:

ERR : Can't implicitly convert from 'i@&' to 'i@'.

opCall access violation

21 July 2014 - 08:59 AM

The following script in 2.29.1 and earlier versions:

class foo {
  void opCall(string) {}
void main() {
  array<foo> bar(1);

causes an access violation on attempt to execute. As far as I can tell, the conditions are rather specific and it's required that opCall has at least one string or string reference (or another similar object) argument and it's also necessary for opCall to be called on an array element (or perhaps another reference) rather than a freestanding instance. If the call to opCall is made explicit, i.e. 


the error will not occur either.


funcdef error

21 July 2014 - 08:44 AM

The following script tested in 2.29.1 and earlier versions:

class foo {}
funcdef void bar(array<foo>);

results in following errors:

array (0, 0) : ERR : The subtype has no default factory
filename.as (2, 24) : ERR : Can't instantiate template 'array' with subtype 'foo'

These errors occur for every funcdef declaration that contains an array with a script-declared class subtype either as a parameter or a return value. Contents of the class don't matter, including whether the class contains an explicitly stated default constructor or not. The error information is certainly incorrect as this kind of an array can be instantiated anywhere outside of the funcdef declaration.

Default constructors vs default arguments

22 August 2013 - 05:45 AM

Let's consider a simple class declared within a script:

class foo{

I can create its instances in both of these two ways:

foo foo1();
foo foo2;

Now let's consider a similar class, but give its constructor a parameter that can have a default value:

class foo{
  foo(int bar=0){

This will still be valid:

foo foo1();

But the other line will return an error:

ERR : No default constructor for object of type 'foo'.


This error will also appear in various other cases such as trying to create a temporary copy of an object. I think that constructors which can be called with no parameters should be treated as default constructors.