Sign in to follow this  
Followers 0
simong

Global variables and const argument by reference.

5 posts in this topic

I'm still quite new to Angelscript and I have some trouble understanding what's going here.

 

I'm trying to pass a global variable in my script to a function that accept a const & parameter. Things seems to work as expected when I use a primitive or a class declared in the same script, but as soon as I'm trying to do this with a type I registered from the application I run directly into a failed assertion:

 

Assertion failed: (useVariable), function PerformFunctionCall, file [...]/angelscript/source/as_compiler.cpp, line 12833.

if( descr->returnType.IsObject() && !descr->returnType.IsReference() ){
		int returnOffset = 0;

		if( descr->DoesReturnOnStack() ){
			asASSERT( useVariable );

			// The variable was allocated before the function was called
			returnOffset = varOffset;
			ctx->type.SetVariable(descr->returnType, returnOffset, true);

			// The variable was initialized by the function, so we need to mark it as initialized here
			ctx->bc.ObjInfo(varOffset, asOBJ_INIT);
		}

It really seems to be related to the fact that the variable I'm trying to pass as a parameter is global and from a custom type. I tried doing the same inside a class and I don't have any problem. As explained above I don't have this issue with primitives or types created in the script, so my first guess would be that I'm doing something wrong with the registration. Which is probably the case as this is the first class I'm trying to register to AS.

 

I'm registering my type as asOBJ_VALUE and asOBJ_APP_CLASS_CDAK.

 

Here's an example code to illustrate what I'm doing.

float test1;
Vec2f test2; // Vec2f is the registered type

void main(){ // main is the function called 

    testFloat( test1 ); // works
    testVec2f( test2 ); // crash with "Assertion Failed"
}

void testFloat( const int &param ){}
void testVec2f( const Vec2f &in param ){}

// the two following work without surprise but I would really prefer
// keeping the const correctness of the class I register to AS
void stupidTestVec2f( const Vec2f param ){}
void stupidTest2Vec2f( Vec2f param ){}

I guess it is somehow related to the way I register my Vec2f type, but I can't seem to find the correct way and I've tried to find solution here without success.

 

As a side question, is "const T &in" the closest to what "const T &" means in c++?

 

Thanks!

Simon.

0

Share this post


Link to post
Share on other sites

An assert from within the AngelScript library is almost certainly a bug in the library itself. It might be triggered by something you're doing incorrectly, but it would still be a bug in AngelScript as it should be reporting an error and not give an assert failure. :)

 

I couldn't reproduce the problem with the latest WIP from the SVN. Can you give that version a try and see if the problem is fixed for you too?

 

"const T &in" is the closest to what "const T &" in C++ means when T is a value type. For reference types you can use "const T &" in AngelScript too.

0

Share this post


Link to post
Share on other sites

I tried the rev 1858 (and the release 2.28.0 & 2.28.1) and unfortunately it doesn't change anything. 

 

I also tried several combination of asOBJ_APP_CLASS_* without any luck, but I did find that it doesn't reach the assertion failed if the type is declared only as asOBJ_VALUE | asOBJ_POD.

 

I tried to make a test as short as possible that still make the application crash:

    // Register the class itself
    r = engine->RegisterObjectType( "Vec2f", sizeof(Vec2f_), asOBJ_VALUE | asOBJ_APP_CLASS_CDAK ); assert( r >= 0 );
    
    
    // Vec2f()
    r = engine->RegisterObjectBehaviour( "Vec2f", asBEHAVE_CONSTRUCT, "void f()",
                                        asFUNCTION(as::BindingHelper::constructor<Vec2f_>),
                                        asCALL_CDECL_OBJLAST); assert( r >= 0 );
    // Vec2f( const Vec2f& src )
    r = engine->RegisterObjectBehaviour( "Vec2f", asBEHAVE_CONSTRUCT, "void f(const Vec2f &in )",
                                        asFUNCTION((as::BindingHelper::constructor<Vec2f_,Vec2f_&>)),
                                        asCALL_CDECL_OBJLAST); assert( r >= 0 );
    
    // ~Vec2f()
    r = engine->RegisterObjectBehaviour("Vec2f", asBEHAVE_DESTRUCT, "void f()",
                                        asFUNCTION(as::BindingHelper::destructor<Vec2f_>),
                                        asCALL_CDECL_OBJLAST); assert( r >= 0 );
    
    // Vec2f& operator=( const Vec2f& rhs )
    r = engine->RegisterObjectMethod("Vec2f", "Vec2f opAssign(const Vec2f &in)",
                                     asFUNCTION((as::BindingHelper::opAssign<Vec2f_,Vec2f_,Vec2f_>)),
                                     asCALL_CDECL_OBJLAST); assert( r >= 0 );

I replaced the original Vec2f class by a dummy one just to be sure (the original class contains all the functions registered above):

class Vec2f_ {
    
};

And here's the script:

Vec2f t;

void main(){
    test( t );
}

void test( const Vec2f &in v ){}

The "as::BindingHelper" above is using the exact same code as the class helper that you can find on the wiki.

 

Here's the full callstack if it's of any help:

 

Screen%20Shot%202014-02-28%20at%2010.55.

Edited by simong
0

Share this post


Link to post
Share on other sites

The assert failure is triggered by the fact that you've registered your opAssign method to return the object by value. 

 

The opAssign method should return the object by reference, i.e. "Vec2f &opAssign(const Vec2f &in)".

 

 

 

Still, there is a bug in the library since it should have recognized this error and reported it to you instead of entering the code path that triggered the assert failure. I'll work on fixing this.

Edited by Andreas Jonsson
0

Share this post


Link to post
Share on other sites

I've fixed the bug in the library in revision 1859.

 

Since it is actually allowed to implement opAssign methods to return objects by value rather than reference, I had to make sure this was properly supported in the compiler. It's not very common to do this however, since you usually want the opAssign to return a reference to the object it is called on so that chained assignment expressions works.

Edited by Andreas Jonsson
0

Share this post


Link to post
Share on other sites

Oh my god! You're right!

I'm not sure how I missed that out! Thank you so much!

 

And thanks for looking into it so quickly!

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0