What is the operator precedence order in Visual Basic 6.0 (VB6)?
In particular, for the logical operators.
Arithmetic Operation Precedence Order
^
- (unary negation)
*, /
\
Mod
+, - (binary addition/subtraction)
&
Comparison Operation Precedence Order
=
<>
<
>
<=
>=
Like, Is
Logical Operation Precedence Order
Not
And
Or
Xor
Eqv
Imp
Source: Sams Teach Yourself Visual Basic 6 in 24 Hours — Appendix A: Operator Precedence
It depends on whether or not you're in the debugger. Really. Well, sort of.
Parentheses come first, of course. Then arithmateic (+,-,*,/, etc). Then comparisons (>, <, =, etc). Then the logical operators. The trick is the order of execution within a given precedence level is not defined. Given the following expression:
If A < B And B < C Then
you are guaranteed the < inequality operators will both be evaluated before the logical And comparison. But you are not guaranteed which inequality comparison will be executed first.
IIRC, the debugger executes left to right, but the compiled application executes right to left. I could have them backwards (it's been a long time), but the important thing is they're different. The actual precedence doesn't change, but the order of execution might.
Use parentheses
EDIT: That's my advice for new code! But Oscar is reading someone else's code, so must figure it out somehow. I suggest the VBA manual topic Operator Precedence. VBA is 99% equivalent to VB6 - and expression evaluation is 100% equivalent. I have pasted the logical operator information here.
Logical operators are evaluated in the following order of precedence:
Not
And
Or
Xor
Eqv
Imp
The topic also explains precedence for comparison and arithmetic operators.
I would suggest once you have figured out the precendence, you put in parentheses unless there is some good reason not to edit the code.
Related
Problem I am facing is that what to do when two operators of same priorities are their?
Example:
If ^ is in the top of stack and ^ comes that what to do?
Should I enter it in stack or just pop out one ^ or both ^ comes out of the stack?
Since both operators are of same precedence, it doesn't matter in which order you execute the calculation as long as there is no bracket involved. You can push it onto stack and do calculation later together or pop the existing one to do the calculation now.
What to do in this case depends on the operator or its specific precedence level, and is referred to as the operator's associativity: https://en.wikipedia.org/wiki/Operator_associativity
Usually + and - have the same precedence and left associativity, for example, meaning a+b-c+d = ((a+b)-c)+d.
The assignment operators usually have right-associativity, meaning a=b+=c=d is the same as a=(b+=(c=d))
I haven't done a detailed survey, but I think that exponentiation operators usually have right associativity, because left associativity is redundant with multiplication, i.e., (a^b)^c = a^(b*c)
This leads to the situation like:
-1 ** 0.5 #=> -1
Only parenthesis remedies it:
(-1) ** 0.5 #=> 6.123031769111886e-17+1.0i
which is less favorable then expected 1.i, but basically acceptable. Before I go to Ruby bugs to complain, I would like to know whether there is perhaps some reason for this to be so?
Many languages define their operator precedence tables by modeling after mathematics' order of operations. In math, exponentiation does have higher precedence than multiplication, and unary negation is a multiplication, after all.
From matz in a reply to "the sign of a number is omitted when squaring it":
People with mathematical background demands precedence for ** being
higher than that of unary minus. That's the reason.
Yes, ** has a higher precedence in Ruby.
Unlike some languages, - is not lex'ed as part of the number literal and is thus just (and universally) the unary - (aka -#). That is, both -x and -1 parse the unary -# as an operator applied to the result of the expression.
Some C-like languages allow multiple statements in the update part of a for statement, e.g.
for (int i = 0; i < limit; i++, butter--, syrup--, pancakesDevoured++)
Java explicitly defines the order for such statements in JLS 14.14.1.2 and 15.8.3 of ECMA-334 (C#) says "the expressions of the for-iterator, if any, are evaluated in
sequence" which I'm reading as left-to-right.
What languages, if any, allow multiple statements in the update part of a for loop but either don't define an ordering for such statements or use an order other than left to right?
edit: removed the C tag since that started a sequence point discussion and there's plenty of that already.
Technically, that's a single expression, not one or more statements, though the distinction isn't super important.
Good old C makes only limited promises about what order expressions like this will be evaluated in. In your example, the order doesn't matter. But consider this expression:
a[i++] = i
If i was 1 before evaluating this expression, should a[1] now equal 1 or 2? As I understand the C specification, the behavior of this expression is undefined, meaning that what you get depends on which compiler you use.
Thanks to #mizo for a readable reference on sequence points, and to #ChrisDodd for pointing out that if you're making simple independent assignments that are separated by the comma operator, C and C++ do fully specify a left-to-right evaluation order.
I know how each of them can be converted to one another but never really understood what their applications are. The usual infix operation is quite readable, but where does it fail which led to inception of prefix and postfix notation
Infix notation is easy to read for humans, whereas pre-/postfix notation is easier to parse for a machine. The big advantage in pre-/postfix notation is that there never arise any questions like operator precedence.
For example, consider the infix expression 1 # 2 $ 3. Now, we don't know what those operators mean, so there are two possible corresponding postfix expressions: 1 2 # 3 $ and 1 2 3 $ #. Without knowing the rules governing the use of these operators, the infix expression is essentially worthless.
Or, to put it in more general terms: it is possible to restore the original (parse) tree from a pre-/postfix expression without any additional knowledge, but the same isn't true for infix expressions.
Postfix notation, also known as RPN, is very easy to process left-to-right. An operand is pushed onto a stack; an operator pops its operand(s) from the stack and pushes the result. Little or no parsing is necessary. It's used by Forth and by some calculators (HP calculators are noted for using RPN).
Prefix notation is nearly as easy to process; it's used in Lisp.
At least for the case of the prefix notation: The advantage of using a prefix operator is that syntactically, it reads as if the operator is a function call
Another aspect of prefix/postfix vs. infix is that the arity of the operator (how many arguments it is applied to) no longer has to be limited to exactly 2. It can be more, or sometimes less (0 or 1 when defaults are implied naturally, like zero for addition/subtraction, one for multiplication/division).
VB has operators AndAlso and OrElse, that perform short-circuiting logical conjunction.
Why is this not the default behavior of And and Or expressions since short-circuiting is useful in every case.
Strangely, this is contrary to most languages where && and || perform short-circuiting.
Because the VB team had to maintain backward-compatibility with older code (and programmers!)
If short-circuiting was the default behavior, bitwise operations would get incorrectly interpreted by the compiler.
The Ballad of AndAlso and OrElse by Panopticon Central
Our first thought was that logical operations are much more common than bitwise operations, so we should make And and Or be logical operators and add new bitwise operators named BitAnd, BitOr, BitXor and BitNot (the last two being for completeness). However, during one of the betas it became obvious that this was a pretty bad idea. A VB user who forgets that the new operators exist and uses And when he means BitAnd and Or when he means BitOr would get code that compiles but produces "bad" results.
I do not find short-circuiting to be useful in every case. I use it only when required. For instance, when checking two different and unconnected variables, it would not be required:
If x > y And y > z Then
End If
As the article by Paul Vick illustrates (see link provided by Ken Browning above), the perfect scenario in which short-circuiting is useful is when an object has be checked for existence first and then one of its properties is to be evaluated.
If x IsNot Nothing AndAlso x.Someproperty > 0 Then
End If
So, in my opinion both syntactical options are very much required.
Explicit short-circuit makes sure that the left operand is evaluated first.
In some languages other than VB, logical operators may perform an implicit short circuit but may evaluate the right operator first (depending for instance on the complexity of the expressions at left and at right of the logical operator).