Jump to content
  • Advertisement

gjl

Member
  • Content Count

    128
  • Joined

  • Last visited

Community Reputation

468 Neutral

About gjl

  • Rank
    Member

Personal Information

  • Role
    Programmer
  • Interests
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I have indeed seen this. Thanks! For implicit constructor conversion, does it mean that the following code will compile? any@ GetAny() { int i=0; return i; }
  2. Have you tried our version? It includes a couple of fixes and we have never had a crash ever since... (running on Mac and Windows). There is indeed a trial version for the DSP scripting plug-in. You can find it on the right of the Plug'n Script plug-in page.
  3. Thanks! This is more than great!
  4. Thanks, it makes sense. I guess I'll have to get rid of the length() method then, as I definitely do not need it! Why this choise of keeping the length function and changing the property to "size" by the way? It looks like it will also break for people using the stl style.
  5. Yes, there is already an official request on github. However I have had another fix for more than a year and it was not reintegrated yet.
  6. gjl

    ASSERT triggered when converting

    Great, thanks!
  7. So you mean that we have to choose between the length() function and the get-length accessor then? I have tried the patch suggested above and it works fine so I am not sure to understand.
  8. Just in case someone is interested in using the excellent JIT compiler by BlindMind studios, you will probably need the following fixes applied: https://github.com/bluecataudio/AngelScript-JIT-Compiler/commit/f6f3ab9d79dda7f520a88c1db7ec5611a12b5b59 It fixes a compilation error due to the new string constants system and a runtime error with types missing addref and release.
  9. By the way, this also applies to the stdstring addon (for which length actually seems more appropriate to me than size anyway 🙂 ).
  10. A strange ASSERT is triggered when trying to cast an object that has multiple opCast operators for differents types: 2> Assertion failed: func->returnType.GetTokenType() == ttVoid && func->parameterTypes.GetLength() == 1 && func->parameterTypes[0].GetTokenType() == ttQuestion, file ..\..\source\as_scriptengine.cpp, line 4918 Having a look at the code it seems this assertion is not valid and should be replaced by an if() statement - otherwise it means that you cannot implement the opCast method with different return types. // Look for ref cast behaviours asCScriptFunction *universalCastFunc = 0; asCObjectType *from = reinterpret_cast<asCObjectType*>(fromType); for( asUINT n = 0; n < from->methods.GetLength(); n++ ) { asCScriptFunction *func = scriptFunctions[from->methods[n]]; if( func->name == "opImplCast" || (!useOnlyImplicitCast && func->name == "opCast") ) { if( func->returnType.GetTypeInfo() == toType ) { *newPtr = CallObjectMethodRetPtr(obj, func->id); // The ref cast behaviour returns a handle with incremented // ref counter, so there is no need to call AddRef explicitly // unless the function is registered with autohandle if( func->sysFuncIntf->returnAutoHandle ) AddRefScriptObject(*newPtr, toType); return asSUCCESS; } // FIXME: check if this is a universal cast operator before storing it instead of asserting else if(func->returnType.GetTokenType() == ttVoid && func->parameterTypes.GetLength() == 1 && func->parameterTypes[0].GetTokenType() == ttQuestion ) { universalCastFunc = func; } } } I have tested the fix above and it seems to be causing no issues (and actually I think it fixes problems in case no appropriate cast is found). What do you think?
  11. Indeed, maybe that's the way to go then. I was just afraid of modifying the specification of strings in the language. I guess an explicit cast is preferred in this case (for literals to strings at least).
  12. It appears that in the array addon, the "length" accessors have been replaced by "size". It's indeed a good idea to have all containers use the same syntax. However, why not keep the old length accessor as well? Otherwise all existing code referring to the length property is broken. I suggest that you simply keep both, to maintain compatibility: // Register virtual properties r = engine->RegisterObjectMethod("array<T>", "uint get_length() const", asMETHOD(CScriptArray, GetSize), asCALL_THISCALL); assert( r >= 0 ); r = engine->RegisterObjectMethod("array<T>", "void set_length(uint)", asMETHODPR(CScriptArray, Resize, (asUINT), void), asCALL_THISCALL); assert( r >= 0 ); r = engine->RegisterObjectMethod("array<T>", "uint get_size() const", asMETHOD(CScriptArray, GetSize), asCALL_THISCALL); assert( r >= 0 ); r = engine->RegisterObjectMethod("array<T>", "void set_size(uint)", asMETHODPR(CScriptArray, Resize, (asUINT), void), asCALL_THISCALL); assert( r >= 0 ); What do you think?
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!