Hi

After recent update, I get lots of "The operand is implicitly converted to handle in order to compare them" warnings, all from "hSth == (or !=) null".
I tried turni[font="Arial"]ng on asEP_ALLOW_IMPLICIT_HANDLE_TYPES, but that doesn't change anything. My handle types don't have copy operators (in fact, with exception of add-on array, they can't be instanced in script), so I could skip all @, and work with handles more like with pointers in c++. Does/will implicit handles work that way?[/font]

[font="Arial"]My engine uses run-time declared types that works like simplified class inheritance. Base class is defined in C++ (and can be derived from other class using single inheritance model) and run-time declared class can add extra properties and events (thanks for update with function pointers [/font][font="Arial"]), this inheritance model is exposed to AS using asBEHAVE_(IMPLICIT)_REF_CAST, and since I don't know how many classes will be declared all casting behaviors are using single function.[/font]

[font="Arial"]void ASClassDownCast(asIScriptGeneric* gen)
{
void* p = gen->GetObject();
gen->SetReturnObject(p);
}

void ASClassUpCast(asIScriptGeneric* gen)
{
ITHEntity* pGE = static_cast(gen->GetObject());
if(pGE == NULL)
{
gen->SetReturnObject(NULL);
return;
}

int RetType = gen->GetReturnTypeId();

const ITHClass* pCls = pGE->GetClass();
while(pCls)
{
if(pCls->GetScriptType() == RetType)
{
gen->SetReturnObject(pGE);
return;
}
pCls = pCls->GetBaseClass();
}

gen->SetReturnObject(NULL);
}
void ASRegisterClassCastOp(asIScriptEngine* engine, const CTHString& SuperCls, const CTHString& DerivedCls)
{
int r = 0;
CTHString Decl;

Decl.Empty();
Decl << SuperCls << "@ f()";
r = engine->RegisterObjectBehaviour(DerivedCls.c_str(), asBEHAVE_IMPLICIT_REF_CAST, Decl.c_str(), asFUNCTION(ASClassDownCast), asCALL_GENERIC); assert( r >= 0 );

Decl.Empty();
Decl << DerivedCls << "@ f()";
r = engine->RegisterObjectBehaviour(SuperCls.c_str(), asBEHAVE_REF_CAST, Decl.c_str(), asFUNCTION(ASClassUpCast), asCALL_GENERIC); assert( r >= 0 );
}

[/font]

[font="Arial"]I found that DownCast is more than 10x faster (I know it does little work). After code inspection i found that [/font][font="Arial"]GetReturnTypeId (or rather GetTypeIdFromDataType) does lots of things (some loops, creating new type id's etc). And the question now. Can return type id be somewhere cashed or how can I speed things up a bit here?[/font]

I somehow missed the purpose for "is" operator, if it is preferred way for handle comparison then I should rewrite my scripts.

I can't use template functions because I don't have any info about derived classes at compile time (they are declared in some config files and loaded when app starts).
Other than that, I use pretty much the same system (but, mine is limited to single parent inheritance only).

Anyway I found quick solution for my performance problem, using Set/GetUserData from asIScriptFunction.
void ASClassUpCast(asIScriptGeneric* gen)
{
ITHEntity* pGE = static_cast(gen->GetObject());
if(pGE == NULL)
{
gen->SetReturnObject(NULL);
return;
}

int RetType = (int)gen->GetFunctionDescriptor()->GetUserData();

const ITHClass* pCls = pGE->GetClass();
while(pCls)
{
if(pCls->GetScriptType() == RetType)
{
gen->SetReturnObject(pGE);
return;
}
pCls = pCls->GetBaseClass();
}

gen->SetReturnObject(NULL);
}
void ASRegisterClassCastOp(asIScriptEngine* engine, const CTHString& SuperCls, const CTHString& DerivedCls)
{
int r = 0;
CTHString Decl;

Decl.Empty();
Decl << SuperCls << "@ f()";
r = engine->RegisterObjectBehaviour(DerivedCls.c_str(), asBEHAVE_IMPLICIT_REF_CAST, Decl.c_str(), asFUNCTION(ASClassDownCast), asCALL_GENERIC); assert( r >= 0 );

Decl.Empty();
Decl << DerivedCls << "@ f()";
r = engine->RegisterObjectBehaviour(SuperCls.c_str(), asBEHAVE_REF_CAST, Decl.c_str(), asFUNCTION(ASClassUpCast), asCALL_GENERIC); assert( r >= 0 );

asIScriptFunction* sf = engine->GetFunctionDescriptorById(r);
sf->SetUserData((void*)sf->GetReturnTypeId());
}



Some numbers to prove, 100000x loop, time in [ms] (before / now)
"empty loop" 5,5 / 5,5
downcast 38,1 / 38,1
upcast 619,2 / 41,9
So I reduced time for upcasting to an order of magnitude of calling simple function (which was my goal).



The way [color=#1C2837][size=2]asEP_ALLOW_IMPLICIT_HANDLE_TYPES works, looks promising, but it doesn't work for registered objects (I got -8 'invalid name' error) yet.
[color=#1C2837][size=2]I'm not convinced with skipping @ at variable declaration though. How would you know what kind of assignment "=" is, if variable type gives no context?
[color=#1C2837][size=2]Basicly I'm ok with "TypeName@ Var;" or even "TypeName@ Var1, Var2; //both are handles", but "@Var1 = Var2" looks very unintuitive for me and is source of 90% of my script errors (that's why I looked at [color=#1C2837][size=2]implicit handles in first place). Could you consider implementing [color=#1C2837][size=2]asEP_ALLOW_IMPLICIT_HANDLE_TYPES as 3-levels property? (like 0 - standard handles, 1 - @ dropped at assignments, 2 - @ dropped everywhere)

Implementing [color=#1C2837][size=2]asEP_ALLOW_IMPLICIT_HANDLE_TYPES was to complex for me (especially without knowledge of how parser and compiler work). Since I'm interested in dropping @ at handle assignments only, I created new engine property which forces that behavior for all reference types. (btw. script declared types are 'value' or 'reference'?)
[color=#1C2837][size=2]

[color=#1C2837][size=2](code sent via e-mail)