[whizzter]

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.

[plq]

> 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:

    import ast;print(ast.dump(ast.parse("2*PI*r*r"),indent=2))

[whizzter]

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).