🔒 Locked

Pointer related bug in Angel Script 1.10 ?

Started by Licu Nov 4, 2004 at 3:15 AM 3 replies 2.3k views

Original Post

Nov 4, 2004 at 3:15 AM

Hi, I've uploaded and tested the new 1.10 version in our engine and we've encountered a problem with global properties that are pointers to classes. I’ve registered a class with: engine->RegisterObjectType("class1", sizeof(Class1), asOBJ_CLASS); // or use asOBJ_GUESS After that registered a global property as a pointer to this class with: engine->RegisterGlobalProperty("class1 *pnt", &pnt); Registered a function member with: engine->RegisterObjectMethod("class1", "void function()", asFUNCTION(function), asCALL_CDECL_OBJFIRST); Trying to execute the function in the script gives me the following compilation error: No matching signatures to “function()” Illegal operation on this datatype Trying to use a member variable crashes the compilation. Here is a test application (constructed in your framework test): #include "utils.h" #define TESTNAME "TestGlobalObjectPointer" class Class1 { }; static void function(Class1 *_this) { } bool TestGlobalObjPointer() { bool fail = false; asIScriptEngine *engine = asCreateScriptEngine(ANGELSCRIPT_VERSION); engine->RegisterObjectType("class1", sizeof(Class1), asOBJ_CLASS); engine->RegisterObjectType("factory", 0, 0); // Register an object. Class1 obj; engine->RegisterGlobalProperty("class1 obj", &obj); // Register a pointer to object. Class1 *pnt = &obj engine->RegisterGlobalProperty("class1 *pnt", &pnt); // Register class function. engine->RegisterObjectMethod("class1", "void function()", asFUNCTION(function), asCALL_CDECL_OBJFIRST); COutStream out; // Function call executed fine when using an object. int r = engine->ExecuteString(0, "obj.function();", &out); if( r < 0 ) { printf("%s: ExecuteString() failed %d\n", TESTNAME, r); fail = true; } // BUG??!! FUNCTION CALL WILL FAIL WHEN USING AN OBJECT POINTER. r = engine->ExecuteString(0, "pnt->function();", &out); if( r < 0 ) { printf("%s: ExecuteString() failed %d\n", TESTNAME, r); fail = true; } // WHEN USING A POINTER TO ACCESS A MEMBER VARIABLE COMPILING CRASHES. engine->Release(); return fail; } Now, probably this is related to previous discussions about removing pointers in Angel Script. If this is not a bug but rather a scripting aspect that is dropped, is it possible to do the same thing with references? Note that I’m not declaring any class objects in the script but rather all the engine interfaces are registered with the scripting engine as global properties. Regards, Adrian Licu Quad Software

WitchLord

Nov 4, 2004 at 8:02 AM

Pointers haven't been dropped yet, so this should work. You've probably encountered a bug. I will verify this during the day, and if the fix is simple I'll post it here.

Thanks for the test case, it should make it much easier to find the problem.

Regards,
Andreas

WitchLord

Nov 4, 2004 at 2:40 PM

I've found the bugs. They were caused by the changes that I made during the implementation of the native array.

The bug fixes are as follows:

In function asCCompiler::CompileExpressionPostOp() (as_compiler.cpp, line 3803):

void asCCompiler::CompileExpressionPostOp(asCScriptNode *node, asCByteCode *bc, sTypeInfo *type){   ...   if( op == ttInc || op == ttDec )   {      ...   }   else if( op == ttDot || op == ttArrow )   {      ...      if( node->firstChild->nodeType == snIdentifier )      {         ...         // Find the property offset and type         if( objType.tokenType == ttIdentifier )         {// start FIX:            if( objType.pointerLevel )            {               // Convert to the type that is being pointed to               objType.pointerLevel = 0;               objType.objectType = objType.extendedType;            }// end FIX            ...         }         else         {            ...         }      }      else      {         ...         // Make sure it is an object we are accessing         if( type->dataType.tokenType != ttIdentifier && type->dataType.arrayDimensions == 0 )         {            ...         }         else         {            // We need the pointer to the object            if( op == ttArrow && type->dataType.isReference )               bc->Instr(BC_RD4);// start FIX:            asCObjectType *trueObj = type->dataType.objectType;            if( op == ttArrow )               trueObj = type->dataType.extendedType;// end FIX:            sTypeInfo objType = *type;            // Compile function call// FIX: changed the parameter            CompileFunctionCall(node->firstChild, bc, type, trueObj);            ...         }      }   }   else if( op == ttOpenBracket )   {      ...   }}

jetro

Nov 7, 2004 at 12:12 PM

I also experienced similar pointer problems with 1.10.0, which seem to be fixed by the above changes. But here's a description of my problem in any case for reference.

AS code was as follows:

UIFont *medFont;uint medFontHeight;void onInit(){    medFont = getFont("medium");    medFontHeight = medFont->getFontHeight();    // ... }

Errors given: (call to method Build returns -1)
Info : Compiling void onInit()
Error : No matching signatures to 'getFontHeight()'
Error : Can't implicitly convert from 'const int' to 'uint&'.

The related source was declared with code snippets as follows:

// getFont declaration:static UIFont * script_getFont(asBSTR *name){    return GameApp::getInstance()->getFont((char *)*name);}res = engine->RegisterGlobalFunction("UIFont * getFont(bstr &name)",                                     asFUNCTION(script_getFont), asCALL_CDECL);// (verify res)// ...// UIFont & getFontHeight declaration:const char *cl = "UIFont";engine->RegisterObjectType(cl, sizeof(UIFont), asOBJ_CLASS);res = engine->RegisterObjectMethod(cl, "uint getFontHeight()",                                   asMETHOD(UIFont, getFontHeight),                                   asCALL_THISCALL);assert(res >= 0);

WitchLord

Nov 7, 2004 at 12:49 PM

Thanks for letting me know. You are describing the exact same problem.

The 1.10.1 WIP 1 (released earlier today) fixes the problem.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.