+ is a binary operator. In mathematics it tends to be associative, i.e. it doesn't matter if you do (a+b)+c or a+(b+c), but it would be resolved by combining two values at a time.
The Java compiler does do the right thing, but by allowing mixed type operations with semantics depending on the types the associativity is broken. Peter Reinier Zwitserloot wrote: > I can confirm that the compiler is completely unaware of multi-arity > operators (the notion that + takes 2 OR MORE elements - it just takes > 2 elements, no more, and multiple applications are merely this notion > chained), and that these are always resolved in a strict left-to-right > fashion. > > You can see the same weird shenanigans when trying to add numbers and > non-numbers together: > > 5 + 3 + "foo" = "8foo". > "foo" + 5 + 3 = "foo53". > > On Aug 27, 10:20 am, Christian Catchpole <[email protected]> > wrote: > >> hmm.. think you missed the point there peter. "two " + "three" == >> "two three" regardless of what comes before it. But I think i might >> know why the optimizer picks up >> >> "one " + "two " + "three" >> >> but not >> >> getOne() + "two " + "three" >> >> it probably sees this.. >> >> (("one " + "two ") + "three") >> == >> (("one two ") + "three") >> == >> ("one two three") >> >> It can collapse one two, then the third because they are all constant. >> >> ((getOne() + "two ") + "three") >> >> the first collapse produces something unpredictable. >> >> On Aug 27, 7:43 am, Peter Becker <[email protected]> wrote: >> >> >> >> >>> Alexey Zinger wrote: >>> >>>> There are quite a few optimizations with strings, for sure. Such as >>>> replacing concatenation using "+" operator with StringBuilder and >>>> concatenation of literals with a single literal (*). >>>> >>>> There's an interesting exception to that rule. The following will >>>> work as expected: >>>> "one " + "two " + "three" >>>> gets turned into >>>> "one two three" >>>> >>>> However, in the context of this: public String getOne() { return "one "; } >>>> this: getOne() + "two " + "three" >>>> will not get turned into >>>> getOne() + "two three" >>>> >>> If I am not mistaken the compiler can not replace that without >>> potentially breaking the code. You method is public and non-final, which >>> means it can be overwritten, so you need the dynamic dispatch, inlining >>> is not ok. >>> >>> The JIT might do a different thing since it knows the state of the >>> running system. If it should optimize that call it will need to be able >>> to revert it if a baseclass of the class you describe is loaded. >>> >>> If the method getOne() would be either final or private, then the >>> compiler should theoretically be able to inline it. No idea if it would. >>> >>> Peter >>> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
