Hi there,

I recently ported our AngelScript gluecode to a recent version (2.20.3). I've rewritten all classes and operator bindings to adhere to the new principle of named functions. Yet if I try to use operators in a script function, I get an error message.

This is the class in question - a simple vector class of 3 floats



mEngine->RegisterObjectType( "TVektor", sizeof(TVektor), asOBJ_VALUE | asOBJ_APP_CLASS_C);
mEngine->RegisterGlobalFunction( "float opMul(const TVektor &in, const TVektor &in)", asFUNCTIONPR( operator *, (const TVektor &, const TVektor &), float), asCALL_CDECL);
mEngine->RegisterGlobalFunction( "TVektor opMul(float, const TVektor &in)", asFUNCTIONPR( operator *, (float, const TVektor &), TVektor), asCALL_CDECL);
mEngine->RegisterGlobalFunction( "TVektor opMul(const TVektor &in, float)", asFUNCTIONPR( operator *, (const TVektor &, float), TVektor), asCALL_CDECL);




All calls are successful. Now I try to use the operator TVektor * float in a script function:


void DestroyTile_3(uint x, uint y, uint layer, TVektor direction, float damage)
{
StartEffect( SomeEffectId, float(x), float(y), 0.0f, direction * damage);
}


and I get an error upon compilation:

No conversion from 'TVektor&' to math type available.[/quote]

Any suggestion what I'm doing wrong? According to my understanding, operator * (TVektor, float) should be invoked, but it isn't. Any hint is appreciated.

Bye, Thomas

The operators should be registered as class methods, not global functions. You don't need to change the implementation of the functions, just the way they are registered.


mEngine->RegisterObjectType( "TVektor", sizeof(TVektor), asOBJ_VALUE | asOBJ_APP_CLASS_C);
mEngine->RegisterObjectMethod( "TVektor", "float opMul(const TVektor &in)", asFUNCTIONPR( operator *, (const TVektor &, const TVektor &), float), asCALL_CDECL_OBJFIRST);
mEngine->RegisterObjectMethod( "TVektor", "TVektor opMul_r(float)", asFUNCTIONPR( operator *, (float, const TVektor &), TVektor), asCALL_CDECL_OBJLAST);
mEngine->RegisterObjectMethod( "TVektor", "TVektor opMul(float)", asFUNCTIONPR( operator *, (const TVektor &, float), TVektor), asCALL_CDECL_OBJFIRST);


Regards,
Andreas

Thanks Andreas!

I already tried that version after seeing the math3d addon, but I forgot to change the calling convention. It still said "CDECL" which lead to a simple "Invalid configuration" error when trying to compile something. Changing this to CDECL_OBJFIRST and CDECL_OBJLAST with the _r option, respectively, solved the issue.

While I'm on it: there's another thing I noticed yesterday. I had problems resolving a constructor call. The aforementioned class has three constructors:


RegisterObjectBehaviour( "TVektor", asBEHAVE_CONSTRUCT, "void f()", asFUNCTIONPR( ScriptHelper::BuildTVektor, (TVektor *), void), asCALL_CDECL_OBJLAST);
RegisterObjectBehaviour( "TVektor", asBEHAVE_CONSTRUCT, "void f(const float)", asFUNCTIONPR( ScriptHelper::BuildTVektor, (const float, TVektor *), void), asCALL_CDECL_OBJLAST);
RegisterObjectBehaviour( "TVektor", asBEHAVE_CONSTRUCT, "void f(float, float, float)", asFUNCTIONPR( ScriptHelper::BuildTVektor, (float, float, float, TVektor *), void), asCALL_CDECL_OBJLAST);


and I compile the following script:


TVektor a( 1, 2, 3); // works fine
TVektor b( 1.0, 2.0, 3.0); // also works
TVektor c( 1.0f, 2.0f, 3.0f); // does not work


the last line yields the following error messages

No matching signatures to 'TVektor(const float, const float, const float)'
Candidates are:
void TVektor::_beh_0_()
void TVektor::_beh_0_(const float)
void TVektor::_beh_0_(float, float, float)
[/quote]

Am I doing something wrong here? Or is there a problem resolving overloads when floats are involved? Because doubles and integers seem to be accepted nicely.

[edit] Weird. I simply removed the "const" at the 1xfloat constructor overload. Now everything including the 3xfloat constructor is working fine. When I bring back the "const" in the 1xfloat constructor, the 3xfloat constructor call is ambiguous again.

That means that for me the issue is solved now, but there might be a bug lurking in the AngelScript overload resolution code.


Bye, Thomas

It does indeed look like a bug in AngelScript. I'll look into it.

Thanks for the report,
Andreas