This line is part of the code that creates an AST-like structure that is then fed into the compiler. The actual multiplication is done by calling the function handle returned from the Compile method.
I think what GP was referring to that there is nothing stopping the code from being designed so that:
AST<float> p1 = exp.GetP1();
AST<float> rsqr = p1 * p1; // AST<float> implements an operator* overload that produces an AST<float> object
Even if many frown upon operator overloading due to the annoying magical-ness of the standard-librarys appropriation of the shift operators for "piping" (<< and >>), it's still what makes many people prefer C++ for vector-math,etc tasks.
So whilst the result isn't a direct multiplication it should still be an acceptable use since the resulting code will actually be doing multiplications.
Considering what goes on under the hood however, I guess there might be some compiler optimization reasons to keep everything in the expression object in the example as the holder of data instead of spread out in an allocation tree with lots of pointer-chasing.
> So whilst the result isn't a direct multiplication it should still be an acceptable use since the resulting code will actually be doing multiplications.
First, nope, if it's not multiplication it should not be using the * operator, period. Operator overloading is already overused and it leads to so much problematic code that looks fine to the untrained eye (string concat using operator+ being a famous example).
That said, you may also want to pass more options to the Mul node in the future and operator*() can only accept two arguments.
As another example, run the following Python code to see how python represents its own AST:
So basically you're saying that if I want to add mathematical expressions to my JIT'ed code I should obfuscate the purpose by writing multi-line operations to build them instead of having the ability to plonk it in more or less verbatim?
As I said, I fully agree that operator overloading is horribly overused but the purpose of this JIT is to quickly create JIT code with customized expressions then those expressions should be possible to write fairly verbatim instead of following something with a religious zeal (is even matrix multiplication allowed to overload?).
And yes, AST's usually contain a lot more information such as source-location,etc for debugging (here it'd be interesting if an operator overload is able to take C++20 source_location as default parameters), but again this is for a specialized jit.
As for passing more options to mul nodes, a mul node is just that and nothing more (only extra interesting data in a restricted scenario as this would possibly be source_location as noted above).
Yes, but what I suspect the commenter was saying is that you can build the expression usung operator overloading as well, so you can type ”a + b”, not ”a.Add(b)”.
I love it when libraries like this do that. z3 in python is similar, you just build your constraints using normal syntax and it all just works. Great use of operator overloading.
Except that's not what's happening. expression.Mul isnt multiplying itself against something, it's adding a Mul instruction to its list. Maybe it would have been more obvious if the method name was insertMul instead.
AST<float> p1 = exp.GetP1();
AST<float> rsqr = p1 * p1; // AST<float> implements an operator* overload that produces an AST<float> object
Even if many frown upon operator overloading due to the annoying magical-ness of the standard-librarys appropriation of the shift operators for "piping" (<< and >>), it's still what makes many people prefer C++ for vector-math,etc tasks.
So whilst the result isn't a direct multiplication it should still be an acceptable use since the resulting code will actually be doing multiplications.
Considering what goes on under the hood however, I guess there might be some compiler optimization reasons to keep everything in the expression object in the example as the holder of data instead of spread out in an allocation tree with lots of pointer-chasing.