sq() (in its current form) is an abortive function that looks to be more trouble than it is worth.
How many variants should one create to make sure their program functions correctly?
I don't know deep details of the machinations of Java compilers nor JVMs, but hazard a guess that even
Code:long lsq(long a) { return a*a; }
is going to cause "problems". What is the overhead/complication in type conversion from int to long, for example? If this is inlined (by the compiler) or somehow optimised by the JVM, is the entire expression likely to be a long (not int) expression, in which case what happens if the result is to be stored in an int or passed to a function requiring an int?
Replacing a basic arithmetic operator that is part of the language with a function call smells like bad news to me.
A while ago I had a play with Eclipse for a couple of days, writing some "optimised" parity test routines (as a curiosity). I seem to recall there being an option to view the bytecode(-ish) output, and thinking it was a pity that it didn't seem smart enough to realise that some variables I'd used had no value beyond some short-term calculations, and were "saved" to memory and "loaded" again with zero benefit whereas I imagine they could rather be left on the arithmetic stack (whatever it is called) for subsequent operations.
I do wonder, though, if a function that returns "a*a" can be inlined/optimised by the compiler/JVM to do a duplicate stack item and multiply.
-spxl
Pages: 1
sq() question? (Read 1085 times)