I’m building a class to handle complex numbers. I’ve created code for Operator_Add, Operator_Subtract, Operator_Multiply and Operator_Divide. These are working fine. Now, I would like to be able to include a numeric literal in the math expression, and have it automatically convert to a type Complex. For example, if a, b and c have been defined as complex, then I’d like to be able to do this:
where the 2.5 literal is converted to a type complex with the real part equal to 2.5 and the imaginary part equal to zero.
I thought that was the purpose of Operator_Convert, but when I define it for an argument of type double, it doesn’t seem to do anything, the math expression gives a syntax error saying “Expected class Complex, but got double.”
Public Function Operator_MultiplyRight(v as Double) as Complex
if you use System.Debuglog(complex) here you could convert it into a string argument.
complex = 123.0
could do something with 123.0
I did eventually implement overloaded versions of all of the operators, and the corresponding right operators, with type Double argument, and that did work.
However, I’m still left wondering, if I had to implement all of those overloaded versions, then what is the purpose of Operator_Convert?
For conversions that dont use an operator.
Var Instance As New MyClass
Var Value As Double = Instance
In this case
Operator_Convert() As Double would be called. The reverse is
Operator_Convert(Value As Double) that acts as a constructor. To be clear, if fires instead of your constructor. It allows for code like
Var Instance As MyClass = 5.0
Okay thanks. I was hoping the compiler would be smart enough to recognize that an operand was different from the final assignment type, and automatically call operand_convert rather than having to have every operator overloaded with every possible operand type. Arrrrgh!
it sees only
why it should convert double to something else?
[quote=481038:@Markus Rauch]it sees only
why it should convert double to something else?[/quote]
the language should convert these to a common type to do the comparison
dim i as integer
dim d as double
if i <> d then // <<< I and/orD are converted to a common type to do the comparison
but there are cases where it doest do this even if operator_convert is defined
but it was a multiplication, a double coverted to own class.
and thom answer about using operator_convert(argument as double) is the right answer
but robert also needs to be aware that operator_compare may give him grief if he writes
if 2.5 <> c then
if c <> 2.5 then
which is the bug report I filed
i think its made for
Var c As Class1
c = 123.4
Var d As double
d = c
his example was
and double was not converted into his class that it looks like
“When is operator convert called”
My answer was “not when you expect it might be or should be”
And the bug report gives one case where you might expect that it could/should be
But it isnt
The OP’s question is very similar
And the answer is “the order the expression is written in may be relevant” - unfortunately
IF you define operator_add then you should also define operator_addright
IF you define operator_multiply then you should also define operator_multiplyright
not doing so can lead to odd compiler bug
but it still doesnt solve the bug report I wrote
in that case the ONLY answer is to actually change the order of the comparison
Okay thanks. I guess I won’t make any more assumptions.
I’ve already discovered that I need to include all of the AddRight, SubtractRight, MultiplyRight etc., methods if I want it to work with doubles. I guess I could have taken the lazy route and just forced the user to convert everything to complex before using it in an expression, but that can get cumbersome.
The Operator_Compare is an interesting case, because other than comparing for equality, I don’t think there is any generally accepted way to determine if one complex number is greater than another one. So I probably don’t need to include this anyway.