Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualJason Goepel

Posted 26 September 2013 - 03:42 PM

I have two classes registered with an implicit value cast:

engine->RegisterObjectBehaviour("TypeA", asBEHAVE_IMPLICIT_VALUE_CAST, "double f() const", ...);
engine->RegisterObjectBehaviour("TypeB", asBEHAVE_IMPLICIT_VALUE_CAST, "double f() const", ...);

The idea behind these classes is that the script writer may use them, in most cases, interchangeably with doubles.  Math operators, in particular, need to work.

TypeA x;
TypeB y;
double z;

z = x * y; 

However, asCCompiler::CompileOperator fails to find a matching operator.  I encountered the following comment in "as_compiler.cpp", line 10814:

// If both operands are objects, then we shouldn't continue
if( lctx->type.dataType.IsObject() && rctx->type.dataType.IsObject() )
{
    asCString str;
    str.Format(TXT_NO_MATCHING_OP_FOUND_FOR_TYPES_s_AND_s, lctx->type.dataType.Format().AddressOf(), rctx->type.dataType.Format().AddressOf());
    Error(str, node);
    ctx->type.SetDummy();
    return -1;
} 

Is there a reason we "shouldn't" continue?  It seems like if both the left and right types objects one could examine all implicit value casts and attempt to find an operator match for those.  Obviously, if one didn't limit the examination to primitive types that search could be infinite.  I was going to attempt such a search.  Do you have any thoughts or reservations?

 

In this particular case I could derive TypeA and TypeB from a "DoubleValue" class which would register all math operations in which I would be interested for the derived types.

 

I would like to clarify.  I am not insisting on this feature, I am just "thinking out loud".  I haven't given this a tremendous amount of thought, and my first impression is that there would be many complications that could arise from such a change. C++ does identify operators from casts though, so I suppose there shouldn't be any fundamental issues.


#2Jason Goepel

Posted 26 September 2013 - 03:37 PM

I have two classes registered with an implicit value cast:

engine->RegisterObjectBehaviour("TypeA", asBEHAVE_IMPLICIT_VALUE_CAST, "double f() const", ...);
engine->RegisterObjectBehaviour("TypeB", asBEHAVE_IMPLICIT_VALUE_CAST, "double f() const", ...);

The idea behind these classes is that the script writer may use them, in most cases, interchangeably with doubles.  Math operators, in particular, need to work.

TypeA x;
TypeB y;
double z;

z = x * y; 

However, asCCompiler::CompileOperator fails to find a matching operator.  I encountered the following comment in "as_compiler.cpp", line 10814:

// If both operands are objects, then we shouldn't continue
if( lctx->type.dataType.IsObject() && rctx->type.dataType.IsObject() )
{
    asCString str;
    str.Format(TXT_NO_MATCHING_OP_FOUND_FOR_TYPES_s_AND_s, lctx->type.dataType.Format().AddressOf(), rctx->type.dataType.Format().AddressOf());
    Error(str, node);
    ctx->type.SetDummy();
    return -1;
} 

Is there a reason we "shouldn't" continue?  It seems like if both the left and right types objects one could examine all implicit value casts and attempt to find an operator match for those.  Obviously, if one didn't limit the examination to primitive types that search could be infinite.  I was going to attempt such a search.  Do you have any thoughts or reservations?

 

In this particular case I could derive TypeA and TypeB from a "DoubleValue" class which would register all math operations in which I would be interested for the derived types.

 

I would like to clarify.  I am not insisting on this feature, I am just "thinking out loud".  I haven't given this a tremendous amount of thought, and my first impression is that there would be many complications that could arise from such a change.


#1Jason Goepel

Posted 26 September 2013 - 02:46 PM

I have two classes registered with an implicit value cast:

engine->RegisterObjectBehaviour("TypeA", asBEHAVE_IMPLICIT_VALUE_CAST, "double f() const", ...);
engine->RegisterObjectBehaviour("TypeB", asBEHAVE_IMPLICIT_VALUE_CAST, "double f() const", ...);

The idea behind these classes is that the script writer may use them, in most cases, interchangeably with doubles.  Math operators, in particular, need to work.

TypeA x;
TypeB y;
double z;

z = x * y; 

However, asCCompiler::CompileOperator fails to find a matching operator.  I encountered the following comment in "as_compiler.cpp", line 10814:

// If both operands are objects, then we shouldn't continue
if( lctx->type.dataType.IsObject() && rctx->type.dataType.IsObject() )
{
    asCString str;
    str.Format(TXT_NO_MATCHING_OP_FOUND_FOR_TYPES_s_AND_s, lctx->type.dataType.Format().AddressOf(), rctx->type.dataType.Format().AddressOf());
    Error(str, node);
    ctx->type.SetDummy();
    return -1;
} 

Is there a reason we "shouldn't" continue?  It seems like if both the left and right types objects one could examine all implicit value casts and attempt to find an operator match for those.  Obviously, if one didn't limit the examination to primitive types that search could be infinite.  I was going to attempt such a search.  Do you have any thoughts or reservations?

 

In this particular case I could derive TypeA and TypeB from a "DoubleValue" class which would register all math operations in which I would be interested for the derived types.

 

 


PARTNERS