Looking for good table with all Java operators
in [Java Help]
|
Prev: ?k???O?T?h???C
Next: JVM and java application
From: Roedy Green on 26 Jan 2010 07:01 On Mon, 25 Jan 2010 21:31:31 +0100, "Robbo" <nie.mam(a)yle.com> wrote, quoted or indirectly quoted someone who said : >Where did you find information that "new" is officially >operator in Java? I am really interested in this topic. >Patricia Shanahan (in this thread) has said that "new" is not an operator. >I have not found any information that would confirm >that "new" is an operator in JLS (3rd edition). I think I read it in Java in a Nutshell, back in the Java 1.0 days. The JLS has refined over the years. Whatever it has to say now about new is the official story. -- Roedy Green Canadian Mind Products http://mindprod.com Don�t be discouraged by a failure. It can be a positive experience. Failure is, in a sense, the highway to success, inasmuch as every discovery of what is false leads us to seek earnestly after what is true, and every fresh experience points out some form of error which we shall afterwards carefully avoid. ~ John Keats (born: 1795-10-31 died: 1821-02-23 at age: 25)
From: Roedy Green on 26 Jan 2010 07:10 On Mon, 25 Jan 2010 21:31:31 +0100, "Robbo" <nie.mam(a)yle.com> wrote, quoted or indirectly quoted someone who said : >If I am right (byte)++x means that ++ is computed before (byte) >-- both (cast) and prefix ++ have the same priority and association >is "Right". >And in (byte)x++, (byte) is first because of higher priority of cast >than postfix ++. >What do you think? My rule of thumb is, if I have to think about precedence, it won't be clear to many other people reading either, and I had better use some more parentheses. There is a fun tool in intelliJ. You write your expression larded with (), and then you ask it to remove nugatory ones. After viewing a number of examples you get to recognise common patters and gotchas. You can also perform some experiments to see how things evaluate. You need to get precedence on a visual level in your brain so you just KNOW how an expression will evaluate. Only at the beginning to you look and precedence numbers and associativity. You learn common patterns, and put it on automatic. I have a mental model that operators are like little gremlins with two little arms that reach out to operands. Some have weak arms. Some have strong ones. When they fight it out, a natural grouping forms, where the strong ones hold the operands more tightly to them. Perhaps someone might create an expression displayer than uses white space around operators to visually and subliminally display the implied precedence. In JDisplay I used various sizes of ( ) and { }. Perhaps something could be done along those lines to help you proofread code. -- Roedy Green Canadian Mind Products http://mindprod.com Don�t be discouraged by a failure. It can be a positive experience. Failure is, in a sense, the highway to success, inasmuch as every discovery of what is false leads us to seek earnestly after what is true, and every fresh experience points out some form of error which we shall afterwards carefully avoid. ~ John Keats (born: 1795-10-31 died: 1821-02-23 at age: 25)
From: Lew on 26 Jan 2010 08:32 Roedy Green wrote: > Perhaps someone might create an expression displayer than uses white > space around operators to visually and subliminally display the > implied precedence. I have one of those. -- Lew
From: Lew on 26 Jan 2010 08:39 Please attribute quotations. Lew wrote: >> As I was corrected upthread (perhaps you missed that post), there is no >> associativity for postfix operators. Robbo wrote: > Ok. Thx. > > > Level Category Operator Associativity > --------------------------------------------------------------- > 1 postfix expr++ expr-- + > --------------------------------------------------------------- > 2 prefix ++expr --expr right+ The same reasoning applies to prefix auto{in,de}crement. It's been pointed out before, although to be fair, to reach the conclusion it would have required thinking about what Patricia posted. > ++(a--) and (++a)-- both apply an operator > requiring a variable to a non-variable value. There's no point talking about associativity of prefix ++ if ++++x is an illegal expression. (Or if it means that unary + is applied twice to ++x - I didn't try it. Why don't you? It'll be a fun experiment.) Thinking about things is a fundamental tool in the programmer's toolbox. -- Lew
From: Thomas Pornin on 26 Jan 2010 09:54
According to Lew <noone(a)lewscanon.com>: > There's no point talking about associativity of prefix ++ if ++++x is an > illegal expression. There is no "associativity" at all for unary operators. Associativity is a notion which is defined only for binary operators. A unary prefix operator applies to what is on its right. A unary postfix operator applies to what is on its left. There is no ambiguity to be lifted with an associativity rule. For instance, "- -x" is to be parsed as "-(-x)" and nothing else, because the unary minus is a prefix operator, not because of some supposed associativity. To be fair, there are some textbooks which talk about "associativity of unary operators" as a convoluted way to say that postfix operators actually have higher or lower precedence than prefix operators. In such texts, you would see that "unary ++ and -- are right-associative" which, in that context, means "postfix ++ and -- have slightly higher precedence than prefix ++ and --". If, in a table of operators, you do not list some prefix and postfix operators as having the same precedence (e.g. you isolate postfix ++ and -- on a line of their own), then you have no need for such contriving of the notion of associativity. > (Or if it means that unary + is applied twice to ++x - I > didn't try it. Why don't you? It'll be a fun experiment.) Java lexing is "greedy" (like in C or C++). This is covered in the JLS, section 3.2: The longest possible translation is used at each step, even if the result does not ultimately make a correct program while another lexical translation would. Thus the input characters a--b are tokenized as a, --, b, which is not part of any grammatically correct program, even though the tokenization a, -, -, b could be part of a grammatically correct program. Doing otherwise would make the parser code quite more complex. --Thomas Pornin |