# Difference between x.opEquals(y) and x==y with funcdefs?

This topic is 1577 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I have a value class with a registered opEquals method that takes a function, like so:
ASengine->RegisterObjectMethod("SOMEVALUETYPE", "bool opEquals(const SOMEFUNCDEF@ &in)", asMETHOD(INTERNALVERSIONOFTHATVALUETYPE,operator==), asCALL_THISCALL);
There is likewise an opAssign method. Any of the following work fine in AngelScript, where svt is a variable of type SOMEVALUETYPE and f is a function of type SOMEFUNCDEF:
svt = f;
svt.opAssign(f);
if (svt.opEquals(f)) {}
However,
if (svt == f) {}

WARN : The operand is implicitly converted to handle in order to compare them
ERR : Both operands must be handles when comparing identity

Shouldn't == work the same way as opEquals, like = works the same way as opAssign? It did in v2.26.3 (or maybe .2, not sure), but seems to have changed at some point since then.

##### Share on other sites

I'll look into this.

##### Share on other sites

I've fixed this bug in revision 1727.

##### Share on other sites
Excellent, thank you!

##### Share on other sites
This feels like a related issue, so I kept in the same topic, but I might be wrong. I mentioned opAssign and = working the same way, but that's not always the case. If the function f is inside of a namespace, then svt.opAssign(ns::f) works just fine, but svt = ns::f crashes. Specifically it would seem to crash the executable at some point during the code compilation, since it doesn't matter if the line never even gets called by anything.
EDIT: The same is true for opEquals/==. Edited by Violet CLM

##### Share on other sites

Thanks. I'll look into it.

##### Share on other sites

I've fixed this problem in revision 1734.

Regards,

Andreas